[Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0

[Christian Heimes]

M.-A. Lemburg schrieb:
> I have a feeling that we should be looking for better merge
> tools, rather than implement code changes that cause more trouble
> than do good, just because our existing tools aren't smart
> enough.

We don't have better tools at our hands. I don't think we'll get any
tools in time or chance the VCS right before a major release.

> Wouldn't it be possible to have a 2to3.py converter
> take the 2.x code (including the C code), convert it and then
> apply any changes to the 3.x branch ?

Such a converter would be nice for 3rd party code but it's not an option
for the core. In the past few months I've merged a lot of code from
trunk to py3k. A 2to3 C converter doesn't help with merge conflicts.
Naming differences make any merge more painful

>> I find the approach less confusing than your suggestion and my initial
>> idea.
> 
> I disagree on that.
> 
> Renaming old APIs to use the new names by adding a header file with
> #define <oldname> <newname> is standard practice.
> 
> Renaming the old APIs in the source code and undoing the renaming
> with a header file is not.

I wasn't talking about standard practice here. I talked about less
confusion for core developers. My approach doesn't split our internal
API in two.
And by the way it *is* a standard approach fore Python. Guido told me
that the same approach was used during the 1.x to 2.0 migration.

> And all this, just because Subversion can't handle merging of
> symbol renaming.

As I said earlier we don't have better tools at our disposal. We have to
make some compromises. Sometimes practicality beat purity.

> Please discuss any changes of the 2.x code base on python-dev.
> 
> Such major changes do need more discussion and possibly a PEP as well.

In the last few months I started at least three topics about the C API
renaming. It's in the thread "2.6 and 3.0 tasks"
http://permalink.gmane.org/gmane.comp.python.devel/93016

Christian