[Python-Dev] 2.6 and 3.0 tasks
Christian Heimes
lists at cheimes.de
Sun Mar 16 18:09:49 CET 2008
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
More information about the Python-Dev
mailing list