[Python-Dev] 2.6 and 3.0 tasks
musiccomposition at gmail.com
Sun Mar 16 19:01:29 CET 2008
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:
> > > 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
> On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <lists at cheimes.de>
> > 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
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...
More information about the Python-Dev