Guido van Rossum wrote:
-1. This will make merging code from 2.6 harder, and causes more work for porting C extensions.
I'm happy to pay the price for the sake of a clean and easy-to-recall C API. The for the C extension problem I already proposed a solution in the thread Benjamin mentioned before. #include "Python.h" #if PY_VERSION_HEX > 0x03000000 #include "python2_compat.h" #endif Where python2_compat provides aliases for PyInt and PyString: #define PyInt_Spam PyLong_Spam ... #define PyString_Egg PyBytes_Egg
* Backport the new buffer protocol to 2.6. I spoke to Travis yesterday and he said he is trying to get it done during the PyCon sprint. Maybe somebody can assist him?
Does he need assistance?
I don't know.
When the new buffer protocol is available in 2.6 we can start back porting bytesarray and the new IO framework.
Are these really so closely tied that they have to wait before they can be backported?
Bytesarray depends on the buffer protocol and the new io framework is much easier to back port when both the buffer protocol and bytesarray is available.
While I know that some people are expecting to use a development model that invokes 2to3 very frequently, I think this is at best a nice-to-have. (I also don't see how it could be done, but maybe I'm blind for the obvious, as the original author.)
I'm not sure if and how 2to3 can be speed up. Maybe some profiling and some C code can increase the speed. It's worth a shot. Christian