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

["Martin v. Löwis"]

M.-A. Lemburg wrote:
> Right, but I don't see the point of each and every
> extension having to go through these hoops when you
> could add support for these checks (including error
> reporting) to the few APIs in question, in particular
> the PyArg_ParseTuple() API.

I don't want to rename the existing APIs, so porters
to ssize_t have an easier life (just fix the compiler
warnings).

As for PyArg_ParseTuple: this already works and requires
no changes either way.

> I don't expect this to happen any time soon for the ten or
> twenty other 3rd party extensions we regularly use and this
> would prevent an upgrade to Python 2.5.

It shouldn't. It could sensibly prevent an upgrade to 64-bit
machines, but there would be no reason not to upgrade on
32-bit machines.

> In particular, functions that currently take int* output
> parameters should continue to do so. New functions should be
> revised to enable Py_ssize_t* output arguments and preseve
> backwards compatibility.
> 
> (This also includes the strategy to be used, so you can
> remove the note on strategy)

Will do.

> Please also add a comment on the fact that extensions
> which haven't been recompiled for the Python 2.5 API
> will not get imported (the API_LEVEL check should consistently
> fail for these instead of just issuing a warning).

I will add it as an open issue. I disagree that this should
actually be done.

>>Would you like to write a specification for that?
> 
> 
> Sure, if there's hope to get this into the code.

I don't know. So far, you are the only one wanting this
kind of change. If the change actually existed, more
people might be willing to voice an opinion - whether
that will be in favour of more hackishness and backwards
compatibility, or against, I cannot guess.

I would personally want to restrict hackishness to places
that the compiler doesn't warn about.

>>To simplify the porting.
> 
> 
> Sorry, I lost you there:
> 
> I'm saying that two sets of APIs (one for int*, one
> for Py_ssize_t*) will make porting easier since
> updated code will only have to rename the APIs
> used. Furthermore, it will allow to write code
> that easily works in Python 2.1-2.4 as well as
> Python 2.5.

Yes, but users of the new API (who would conceptually
do the right thing) would need more effort, just to
protect users who do nothing (which conceptually do
the wrong thing). By just editing the APIs (instead
of also renaming them), I simplify the porting.

> I'm talking about the few APIs that use output parameters.
> Those do support error reporting.

Hmm. I think I could personally accept a change that uses
macro tricks to do all that, i.e. keep the output parameters
at int* if some macro (Py_SIZE_T_CLEAN) is not defined,
and use Py_ssize_t* if it is defined. People would then get
the right warnings still, but no changes would be necessary
to "old" code.

Regards,
Martin