A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-March/109637.html below:

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

[Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple [Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple"Martin v. Löwis" martin at v.loewis.de
Mon Mar 21 04:09:35 CET 2011
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.

Given the recent discussion about backwards compatibility: what's
the best approach? What warning should be emitted, if any?
(the warning would only be generated if an s# or similar format
 was actually encountered - not just if merely PyArg_ParseTuple is
 called).

Regards,
Martin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4