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,
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4