[Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple (original) (raw)
Victor Stinner victor.stinner at haypocalc.com
Mon Mar 21 16:26:08 CET 2011
- Previous message: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
- Next message: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 PyArgParseTuple: >> one outputting int; the other one outputting Pyssizet. >> >> 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 Pyssizet 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-Pyssizet 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.
But when you switch to Py_ssize_t, you may get errors because Py_ssize_t may be casted to a narrower type (like int).
Victor
- Previous message: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
- Next message: [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]