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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
