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, Lithuania39 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,
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
