[Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple

[Stefan Behnel]

Victor Stinner, 21.03.2011 16:26:
> Le lundi 21 mars 2011 à 15:35 +0100, Stefan Behnel a écrit :
>> Victor Stinner, 21.03.2011 15:21:
>>> Le lundi 21 mars 2011 à 04:09 +0100, "Martin v. Löwis" a écrit :
>>>> Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
>>>> one outputting int; the other one outputting Py_ssize_t.
>>>>
>>>> The former should have been removed in 3.0, but this was forgotten.
>>>>
>>>> Still, I would like people to move over to the new version, so
>>>> that extension modules will typically support 64-bit collections
>>>> well. Therefore, I'd like to propose that the int version is deprecated
>>>> in 3.3.
>>>
>>> By the way, what is the status of migration to Py_ssize_t of CPython
>>> extensions? I suppose that adding a warning will quickly give an answer.
>>
>> You'll get a series of very visible warnings from the C compiler when
>> compiling a non-Py_ssize_t extension on a 64bit platform, which is a rather
>> common platform type these days. So I'd doubt that there are any
>> still-in-use extensions left that have not migrated.
>
> Which instrution does emit a warning? If a module still use int, the
> compiler was not emit any warning on call to PyArg_Parse*() because the
> size arguments are passed as pointers in the magical "..." argument.

Ah, I thought you were talking about Py_ssize_t migration in general, not 
specific to the PyArg_Parse*() functions. I faintly remember seeing lots of 
Py_ssize_t related warnings in Pyrex code ages ago (I think my first Pyrex 
patches date back to the time when Py2.5 came out). They were at least 
obvious to me at the time.

But now that I think about it, I guess it's a lot easier to miss a place 
like PyArg_Parse*() when manually migrating code. The conversion of the 
type string is really not obvious and the C compiler can't provide any 
help. I dropped their usage in Cython years ago for performance reasons, 
but I think Pyrex still uses them, and they are extremely common in hand 
written C code as well as code generated by several wrapper generators, 
which tend to have their own ways of declaring input types. So it's 
actually hard to tell how well extensions are prepared here.

Stefan