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

"Martin v. Löwis" martin at v.loewis.de
Tue Jan 10 22:35:30 CET 2006


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.

> 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).

> 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.

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

> Would it be possible to host the PEP in the python.org
> wiki or maybe in the sandbox on svn.python.org ?

I pinged the PEP editors again, and they assigned
the PEP number.

Hosting it in a Wiki would be besides the point of
the PEP process.

Regards,
Martin



More information about the Python-Dev mailing list