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