[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