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

[Gregory P. Smith]

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.

-gps