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

["Martin v. Löwis"]

M.-A. Lemburg wrote:
> What if x64 has a 64-bit value ? How do you catch
> and process the truncation error ?

We were *both* discussing a scenario where no sizes
exceed 2**31, right?

Under such a scenario, this just won't happen.

OTOH, if you were discussing a scenario where sizes
might exceed 2**31, then I don't see why you are worried
about Py_ssize_t* parameters alone: Even

  PyString_Size()

might (of course!) return a value > 2**31 - so it
is not just output parameters, but also return values.

For more information, please read "Conversion guidelines"
in

http://www.python.org/peps/pep-0353.html

>>That is not necessary. Can you give in example of a module
>>where you think it is necessary?
> 
> 
> If you want to port the extension to Py_ssize_t, this
> is essentially the case.
> 
> You might want to take the unicodeobject.c file as
> example.

unicodeobject.c is not an extension. We were discussing
existing extension modules.

> We could use the type flags for these. much like we
> do for the new style numbers.

Would you like to write a specification for that?

> If you don't like the macro approach, why not simply
> leave the two separate sets of APIs visible.

To simplify the porting.

> All Py_ssize_t aware and compatible extensions
> would use the new APIs instead. The old-style APIs
> should then take care of the proper down-casting and
> error reporting.

That is not possible. Some API does not support
error reporting (like PyString_Size()). So callers
don't expect it to fail.

Regards,
Martin