[Python-Dev] Documenting the ssize_t Python C API changes (original) (raw)

M.-A. Lemburg mal at egenix.com
Tue Mar 21 18:07:31 CET 2006

Martin v. Löwis wrote:

M.-A. Lemburg wrote:

Interesting: A few mails ago you suggested that developers do exactly what I did to get the list of changes. Now you gripe about the output format of the grep. Developers which use grep can read the output of grep. Developers which use other methods of searching (e.g. Visual Studio) can understand the output of these tools. I don't say they should search for Pyssizet, I said they can if they want to. I still don't think anybody would want to read such a list.

They don't necessarily want to read it, but like Fredrik did, use as input for their testing tools.

I really don't understand what your problem is with documenting the work that you and others have put into this. Why is there so much resistance ? Because I think it is pointless, confusing, and redundant in a dangerous way. There is absolutely NO problem with API changes where a function consumes Pyssizet. Why should anybody care that PyStringFromStringAndSize now consumes a Pyssizet? Passing an int works just fine, and if the int fits the length of the string, it will absolutely do the right thing. There is no need to touch that code, or worry about the change. Putting PyStringFromStringAndSize into such a list will make developers worry, because they now think they have to change their code somehow, when there is absolutely for action.

Don't you think developers are capable enough to judge for themselves ?

They might also want to change their extensions to make use of the new possibilities, so a list of APIs taking Py_ssize_t parameters on input would be handy to check where there's potential for such a change in their code.

Perhaps we should have three lists:

  1. Py_ssize_t output parameters (these need changes)
  2. Py_ssize_t return values (these need overflow checks)
  3. Py_ssize_t input parameters (these can be used to enhance the extension)

Here's the list for 2 (I already provided the list for 1 in the other mail):

./dictobject.h: -- PyAPI_FUNC(Py_ssize_t) PyDict_Size(PyObject *mp); ./tupleobject.h: -- PyAPI_FUNC(Py_ssize_t) PyTuple_Size(PyObject *); ./stringobject.h: -- PyAPI_FUNC(Py_ssize_t) PyString_Size(PyObject *); ./longobject.h: -- PyAPI_FUNC(Py_ssize_t) _PyLong_AsSsize_t(PyObject *); ./intobject.h: -- PyAPI_FUNC(Py_ssize_t) PyInt_AsSsize_t(PyObject *); ./abstract.h: -- PyAPI_FUNC(Py_ssize_t) PyObject_Size(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PyObject_Length(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) _PyObject_LengthHint(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PySequence_Size(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PySequence_Length(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PyMapping_Size(PyObject *o); -- PyAPI_FUNC(Py_ssize_t) PyMapping_Length(PyObject *o); ./unicodeobject.h: -- PyAPI_FUNC(Py_ssize_t) PyUnicode_GetSize( -- PyObject unicode / Unicode object */ -- ); -- PyAPI_FUNC(Py_ssize_t) PyUnicode_AsWideChar( -- PyUnicodeObject unicode, / Unicode object */ -- register wchar_t w, / wchar_t buffer / -- Py_ssize_t size / size of buffer */ -- ); -- PyAPI_FUNC(Py_ssize_t) PyUnicode_Tailmatch( -- PyObject str, / String */ -- PyObject substr, / Prefix or Suffix string / -- Py_ssize_t start, / Start index / -- Py_ssize_t end, / Stop index / -- int direction / Tail end: -1 prefix, +1 suffix */ -- ); -- PyAPI_FUNC(Py_ssize_t) PyUnicode_Find( -- PyObject str, / String */ -- PyObject substr, / Substring to find / -- Py_ssize_t start, / Start index / -- Py_ssize_t end, / Stop index / -- int direction / Find direction: +1 forward, -1 backward */ -- ); -- PyAPI_FUNC(Py_ssize_t) PyUnicode_Count( -- PyObject str, / String */ -- PyObject substr, / Substring to count / -- Py_ssize_t start, / Start index / -- Py_ssize_t end / Stop index */ -- ); ./listobject.h: -- PyAPI_FUNC(Py_ssize_t) PyList_Size(PyObject *);

Furthermore, it is redundant because there are now four places where the signature of the API is mentioned: in the header, in the implementation, in the API docs, and in the PEP. The compiler watches for consistency of the first two; consistency of the others is a manual process, and thus error-prone.

It's a one-time operation, documenting the changes between Python 2.4 and 2.5 - much like the grand renaming in the C API a few years ago.

You'd only create the lists once in the PEP, namely when Python 2.5 is released.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Mar 21 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 mailing list