[Python-3000] 2.6 and 3.0 tasks

[Christian Heimes]

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. 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'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. ;)

Christian