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

[M.-A. Lemburg]

On 2008-05-28 19:08, Bill Janssen wrote:
>> I'm beginning to wonder whether I'm the only one who cares about
>> the Python 2.x branch not getting cluttered up with artifacts caused
>> by a broken forward merge strategy.
> 
> I share your concern.  Seems to me that perhaps (not sure, but
> perhaps) the rush to back-port from 3.x, and the concern about
> minimizing pain of moving from 2.x to 3.x, has become the tail wagging
> the dog.

Indeed.

If the need to be able to forward merge changes from the 2.x trunk
to the 3.x branch is the only reason for the current approach, then
we need to find a better procedure for getting patches to 2.x
forwarded to 3.x.

I believe that everyone is aware that 3.x breaks things and that's
fine.

However, the reason for introducing such breakage in 3.x
is that users have the option to decide whether and when to switch
to the new major version.

Being able to play with 3.x features in 2.x is nice, but I wouldn't
really consider those essential for 2.x. It certainly doesn't
warrant causing major problems in the 2.x releases.

The module renaming backport was one example (which was undone again),
the C API renaming is another. I expect more such features to be
backported from 3.x to 2.x (even though I don't really think it's
worth the trouble) and since this always means that changes have
to applied in two worlds, we'll need a better process for getting
changes in one major release ported to the other.

Simply tweaking 2.x into shape so that the rather simple minded
SVN merge command works, isn't a good enough procedure for this.

That's why I suggested to use an intermediate form or branch
for the merging - one that implements the 2.x with all renaming
and syntax fixing applied.

This would:

  * reduce the number of merge conflicts since the renaming
    would already have happened

  * reduce the patch sizes that have to be applied to 3.x in
    order to stay in sync with 2.x

  * result in a tool chain that makes it easier for all Python
    users to port their code to 3.x

  * simplify renaming or reorg of modules, functions, methods
    and C APIs without requiring major changes on either side

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 29 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            38 days to go

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611