[Python-Dev] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...) (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Tue Jan 10 22:23:42 CET 2006

M.-A. Lemburg wrote:

... and then the type change of that variable propagates throughout the extension.

That depends on the usage of the code. If the variable is passed by value, no further changes are necessary. If a pointer to the variable is passed, you could replace it with

Py_ssize_t x64; int x; foo(&x64); x = x64;

Then use x as you did with the original code.

You basically end up having to convert the whole extension to Pyssizet.

That is not necessary. Can you give in example of a module where you think it is necessary?

Don't get me wrong: I don't mind doing this for the eGenix extensions, but I'm worried about the gazillion other useful extensions out there which probably won't get upgraded in time to be used with Python 2.5.

I agree that it is not acceptable to require immediate whole-sale updates of every modules. However, I do believe that the number of modules that need any change at all is small, and that those modules can be modified with minimal effort to "get them working again, backwards-compatible" (i.e. with the only exception that they would fail if indices run above 2**31).

I think all it takes is a set of new APIs for functions that use Pyssizet as output parameter and which are mapped to the regular API names if and only if the extension #defines PYSSIZETCLEAN (or some other capability flag).

That is not enough. You also need to deal with the function pointers that change.

Also, others have rejected/expressed dislike of the PY_SIZE_T_CLEAN macro already, so they would probably dislike further hackishness in that direction.

Anyway, I have installed the PEP onsite, and added an "Open Issues" section, recording your comments.

Regards, Martin

More information about the Python-Dev mailing list