[Python-Dev] 2.6 and 3.0 tasks

[Guido van Rossum]

On Sun, Mar 16, 2008 at 1:04 PM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
>   > 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.
>
>  I'm fully aware of the extra burden. The removal of the PyInt_*
>  functions is already causing merge conflicts and compile errors.

Even though the more popular PyInt_ APIs are still available (even if
only as macros).

>  Nearly every C code merge contains at least one place that requires manual
>  intervention. The PyInt merge conflicts are trivial to fix - so would
>  errors caused PyString -> PyBytes rename.

I disagree. Bad merges are already a frequent cause of instability in
3.0. This could easily double the problems. And while I want to reduce
the instability (I really wish you would no commit until all unittests
pass), I also don't want the merges to cost more of your time!

>  I'm not worried about the extra work since it's usually trivial and fast
>  to fix. I'm more worried about the API names. Do you *really* want to
>  drag down dead bodies along the road for the next ten years? The dead
>  bodies are going to rot and stink sooner than later. By Python 3.2
>  everybody surely regrets the confusing names. ;)

It doesn't have to be so black and white. Using the macro approach you
propose we can fix the situation at any time later.

We could also make the changes in 2.6, so that the 2.6 code looks the
same as 3.0. (However for binary compatibility I think it would be
better if in 2.6 the linker sees PyString where in 3.0 it sees
PyBytes.)

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