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

_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.c
om