[Python-Dev] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)
mal at egenix.com
Tue Jan 10 22:05:39 CET 2006
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>>> I don't believe the change is major. It only affects a few extensions,
>>> and for these, it is only a minor change. A single line of changing
>>> will be enough.
>> This is true for all the changes related to parameters passed by
>> value. It is not true for output parameters. For these, the
>> change will propagate into the extension and make quite a few
>> changes necessary (for the same reason you have to change
>> so many variables to Py_ssize_t).
> For the output parameter, just the variable receiving
> the value needs to be changed, and you are done.
... and then the type change of that variable propagates
throughout the extension.
You basically end up having to convert the whole extension
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.
>> We should make it possible to have a simple recompile of old
>> extensions continue to work with Python 2.5 (albeit without
>> them supporting 64-bit indexes) and without introducing
>> segfaults or buffer overflows that way.
> I cannot see how this could reasonably achieved for arbitrary
> extension modules.
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
Professional Python Services directly from the Source (#1, Jan 10 2006)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
More information about the Python-Dev