[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