[Python-Dev] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)

["Martin v. Löwis"]

M.-A. Lemburg wrote:
> ... and then the type change of that variable propagates
> throughout the extension.

That depends on the usage of the code. If the variable
is passed by value, no further changes are necessary.
If a pointer to the variable is passed, you could replace
it with

  Py_ssize_t x64; int x;
  foo(&x64);
  x = x64;

Then use x as you did with the original code.

> You basically end up having to convert the whole extension
> to Py_ssize_t.

That is not necessary. Can you give in example of a module
where you think it is necessary?

> Don't get me wrong: I don't mind doing this for the eGenix
> extensions, but I'm worried about the gazillion other
> useful extensions out there which probably won't get
> upgraded in time to be used with Python 2.5.

I agree that it is not acceptable to require immediate
whole-sale updates of every modules. However, I do
believe that the number of modules that need any change
at all is small, and that those modules can be modified
with minimal effort to "get them working again,
backwards-compatible" (i.e. with the only exception that
they would fail if indices run above 2**31).

> I think all it takes is a set of new APIs for functions
> that use Py_ssize_t as output parameter and which are
> mapped to the regular API names if and only if the
> extension #defines PY_SSIZE_T_CLEAN (or some other
> capability flag).

That is not enough. You also need to deal with the
function pointers that change.

Also, others have rejected/expressed dislike of the
PY_SIZE_T_CLEAN macro already, so they would probably
dislike further hackishness in that direction.

Anyway, I have installed the PEP onsite, and
added an "Open Issues" section, recording your
comments.

Regards,
Martin