[Python-Dev] 2.6 and 3.0 tasks

[Benjamin Peterson]

On Sun, Mar 16, 2008 at 12:32 PM, Guido van Rossum <guido at python.org> wrote:

> On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> [Guido]
> > > That's a rather long thread. Was any conclusion reached? I'm not sure
> > > how introducing a set of aliases will help merging 2.6 code to 3.0.
> > > Can you or Christian describe the proposed approach in more detail?
>
> > As far as I can see, no objections were raised in that thread.
>
> Hm. I had wanted to register a complaint, but I guess I was too busy.
>
> > Christian explained the probable approach:
> > http://mail.python.org/pipermail/python-dev/2008-March/077362.html
>
> That's not much of a plan. It doesn't discuss any of the effects of
> the proposed change on merging code from the 2.6 trunk to the py3k
> branch.
>
> On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <lists at cheimes.de>
> wrote:
> > 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
>
> So this doesn't address merges at all. Suppose we have some C code
> that's shared between 2.6 and 3.0 and manipulates binary data (e.g.
> the gzip codec). It currently uses PyString on both branches, so any
> changes to the trunk merge smoothly into the py3k branch. But if you
> change PyString -> PyBytes in the py3k branch, every change you make
> in the 2.6 code will cause a merge conflict. Is that really what you
> want? I worry that it will effectively separate the trunk and the py3k
> branch, losing the advantage of doing development that effects both at
> once.

We could backport the python2_compact header.

>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/<http://www.python.org/%7Eguido/>
> )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20080316/99e23fbc/attachment.htm