In general, the Python C/API manual is very careful to document when
changes have occurred in the API, this is really useful information when
writing portable extension modules to be used with different Python
versions.

However, there is a group of changes that are not documented.  In Python
2.5 the Py_ssize_t type was introduced, and a number of functions had
arguments changed from int to Py_ssize_t (a trivial change) or from int*
to Py_ssize_t*.  The latter is an incompatible change on 64-bit
platforms, as int and Py_ssize_t have different size, and this DOES
break extension modules on 64-bit platforms.  For example, the change in
int PySlice_GetIndices breaks the Scientific Python NetCDF module badly.

I suggest that a note is added to the documentation of all functions
taking a Py_ssize_t* argument stating that the type of the argument was
changed in Python 2.5.

Best regards

Jakob

I think the Py_ssize_t change is clearly documented in the "What's new"
document:
http://docs.python.org/whatsnew/2.5.html#pep-353-using-ssize-t-as-the-index-type
This paragraph also links to:
http://www.python.org/dev/peps/pep-0353/#doesn-t-this-break-much-code
which happens to mention the incompatibility in the slice API.

Didn't you get any compilation warning?

I suggest to use a newer version of Scientific Python: 2.7 at least uses
Py_ssize_t throughout its code.

Don't get me wrong:  I am not complaining about the code breakage, it is
unavoidable as long as Python is a developing language.  As you say I
can use newer versions of at least some of the modules.  I just think it
would be nice for developers that occasionally write python modules to
have the information at hand in the C/API manual, since that is where
they will be looking when writing the module.

I don't think that we will change the 2.5 manuals anymore; Python 2.5 is
about to see its last bug-fix release.

For 2.6, I suppose contributions would be welcome.

I agree with Martin. Patches are welcome.

How does this look as an initial idea?

Why not use .. versionchanged?

Pure ignore. Let me adjust the patch. Do we prefer versionchanged before
or after versionadded? I am guessing after versionadded so we get a
better chronological view. Although there's something to be said for a
reverse chronological view too.

Committed a first batch in r71910.

Fixed the slice stuff in r71915.

OK, I went through the entire C API documentation and marked up every
part that changed from int to Py_ssize_t in our documentation.

Merged 2.6 and py3k what was appropriate.