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