On 2008-05-28 22:47, Gregory P. Smith wrote:
On Wed, May 28, 2008 at 3:12 AM, M.-A. Lemburg <[EMAIL PROTECTED]> 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
_______________________________________________
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
