[Python-Dev] New PEP: Using ssize_t as the index type

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> If it were this easy, I wouldn't have objections. But it's
>> not.
> 
> It is so easy. Can you should me an example where it isn't?
> 
>> The variables you use with these APIs tend to propagate
>> through the extension, you use them in other calls,
>> make assignments, etc.
> 
> They only propage if you make them. You don't have to,
> if you don't want to.
> 
>> If you implement extension types, you end up having to
>> convert all the length related struct variables to
>> Py_ssize_t.
> 
> Only if you want to. If not, the module will work
> (nearly) unmodified. Of course, it will be limited
> to 32-bit indices.

See my other reply on this topic.

>> All this is fine, but it's also a lot of work which
>> can be made easier. Recompiling an extension is well
>> within range of many Python users, manually checking,
>> fixing and porting it to the new API is certainly not.
> 
> Sure. However, most users will compile it on 32-bit
> systems. If they find they cannot get it to work on
> a 64-bit system, they should ask the author for help,
> or just use it in 32-bit mode (as 64-bit mode won't
> gain them anything, anyway).

I wonder how you are going to import a 32-bit
extension into a 64-bit binary of Python.
It simply doesn't work.

>> The set of functions that will require Py_ssize_t
>> is getting larger in your branch which is why I started
>> this discussion.
> 
> How so? I did not add a single function that has
> int* output values, AFAICT.

No, but there are quite a few APIs with Py_ssize_t*
output values.

> I am talking about the entirety of these functions,
> and claim that they are rarely used (including the
> Unicode and buffer APIs).

I wouldn't say that PyString_AsStringAndSize() is rarely
used and neither is PyArg_ParseTuple().

I agree that other APIs are certainly more domain
specific and can be dealt with in the extension, but
those two APIs need special care and so do the type
slot functions.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 12 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 ! ::::