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
_______________________________________________
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
