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

[M.-A. Lemburg]

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 ?

We're having lengthy discussions about the addition of single method
to an object, but such major changes just go in like that and nobody
seems to really care.

Puzzled,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 28 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            39 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


On 2008-05-27 12:10, M.-A. Lemburg wrote:
> On 2008-05-26 23:34, Christian Heimes wrote:
>> M.-A. Lemburg schrieb:
>>> Isn't that an awefuly confusing approach ?
>>>
>>> Wouldn't it be better to keep PyString APIs and definitions in
>>> stringobject.c|h
>>>
>>> and only add a new bytesobject.h header file that #defines the
>>> PyBytes APIs in terms of PyString APIs ? That maintains
>>> backwards compatibility and allows Python internals to use the
>>> new API names.
>>>
>>> With your approach, you've basically backported the confusing
>>> notion in Py3k that str() maps PyUnicode, only that in Py2
>>> str() will now map to PyBytes.
>>
>> The last time I brought up the topic, I had a lengthy discussion with
>> Guido. At first I wanted to rename the API in Python 3.0 only. Guido
>> argued that it's going to cause too much merge conflicts. He then
>> suggested the approach I implemented today.
> 
> That's the same argument that came up in the module renaming
> discussion.
> 
> 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.
> 
> 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 ?
> 
> This wouldn't be merging in the classical sense, it would be
> automated forward porting.
> 
>> 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.
> 
>> The internal API names are consistent for Python 2.6 and 3.0. The
>> byte string C API is prefixed PyBytes and the unicode C API is prefixed
>> PyUnicode. A core developer has just to remember that 'str' is a byte
>> string in 2.x but an unicode object in 3.0.
> 
> So you've solved part of the problem for 3.x by moving the naming mixup
> back to 2.x.
> 
>> Extension developers don't have to worry at all. The ABI and external
>> API is mostly the same and still exposes the 'str' functions as PyString.
> 
> Well, yes, but only due to a preprocessor hack that turns the
> names used in bytesobject.c back into names you'd normally look
> for in stringobject.c.
> 
> And all this, just because Subversion can't handle merging of
> symbol renaming.
> 
>>> You'd have to add an aliase bytes -> str to the builtins to
>>> at least reduce the confusion a bit.
>>
>> Python 2.6 already has an alias bytes -> str
>>
>>> Yes, but please let's first discuss this some more. I don't think
>>> that the timing was right.... you started this thread just yesterday
>>> and the patches are already checked in.
>>
>> I'm sorry if I was too hasty for you. I got +1 from a couple of
>> developers and it's basically Guido's suggestion.
> 
> 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.
> 
> Thanks,