[Python-Dev] 2.6 and 3.0 tasks

[Benjamin Peterson]

On Sun, Mar 16, 2008 at 1:01 PM, Benjamin Peterson <
musiccomposition at gmail.com> wrote:

>
>
> 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.
>
Sorry, that needs some explanation. We could do the opposite that we do for
Py3K: Add a header file aliasing PyBytes to PyString.

>
>
> >
> > --
> > --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/5cd56eed/attachment.htm