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 Py_ssize_t. 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 Py_ssize_t as output parameter and which are > mapped to the regular API names if and only if the > extension #defines PY_SSIZE_T_CLEAN (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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
