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

[M.-A. Lemburg]

On 2008-05-28 22:47, Gregory P. Smith wrote:
> On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg <mal at egenix.com> 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.
>>
>> How can it be that we allow major C API changes such as the renaming
>> of the PyString APIs to go into the trunk without discussion or
>> a PEP ?
> 
> I do not consider it a C API change.  The API and ABI have not
> changed.  Old code still compiles.  Old binaries still dynamically
> load and work fine.  (I just confirmed this by importing a couple
> python2.4 .so files into my non-debug build of 2.6 trunk)
> 
> A of the PyString APIs are the real implementations in 2.x and are
> still there.  We only switched to using their PyBytes equivalent names
> within the Python trunk code base.
> 
> Are you objecting to our own code switching to use a different name
> even though the actual underlying API and ABI haven't changed?  I
> suppose to people reading the code and going against old reference
> books it could be confusing but they've got to get used to the new
> names somehow and sometime.
> 
> I strongly support changes like this one that makes the life of
> porting C code forwards and backwards between 2.x and 3.x easier
> without breaking compatibility with earlier 2.x version because that
> is going to be a serious pain for all of us otherwise.

Well, first of all, it is a change in the C API:
APIs have different names now, they live in different files,
the Python documentation doesn't apply anymore, books have to
be updated, programmers trained, etc. etc. That's fine for
3.x, it's not for 2.x.

Second, if you leave out the "ease merging" argument, all of
this is not really necessary in 2.x. If you absolutely want
to have PyBytes APIs in 2.x, then you can *add* them, without
removing the PyString APIs. We have done that on a smaller
scale a couple of times in the past (turned functions into
macros or vice-versa).

And finally, the "merge" argument itself is not really all that
strong. It's just a matter of getting the procedure corrected.
Then you can rename and restructure as much as you want in
3.x - without affecting the stability and matureness of the
2.x branch.

I suspect more of these backports to happen, so we better get
things done right now instead of putting Python's reputation
as stable and mature programming language at risk.

-- 
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