On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson
<musiccomposition@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@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.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)