[Python-Dev] New PEP: Using ssize_t as the index type (original) (raw)

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

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