Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-05-27 12:56, Thomas Heller wrote:
M.-A. Lemburg schrieb:
On 2008-05-26 23:34, Christian Heimes wrote:
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
M.-A. Lemburg schrieb: 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.
There are applications out there that dynamically import the python dll and link to the exported functions by name; they will all break.
The exported APIs still use the old names. Just the source code versions of the APIs change to the new names and they now live in different files as well.
I believe in the past we have been more carefull with changes like these. Even when python api functions were turned into cpp macros, we provided exported functions for them; for a few examples see the function definitions near line 1778 in file Python/pythonrun.c .
IMO, we should keep using that strategy for Python 2.x. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 27 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 40 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M.-A. Lemburg wrote: | The exported APIs still use the old names. Just the source code | versions of the APIs change to the new names and they now live | in different files as well. Do we need to change "PYTHON_API_VERSION"?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ ~ _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDwAt5lgi5GaxT1NAQKvUwP+Lc605lolQAwcOc9lgM37m91lIqbBopws H7nzQqYjkQFISmXMNzeFwEzo6HPcLv0Phw1ghXF3zE1rQE6APcJX8CG5nMsvjSRO XTW4fKcnVEEcH0NH9WgSjp+v28gMOsfE4ppC1rjhYiJ5M3gIfVlFXrsNeboycvlf L0YM998L5Bw= =seNU -----END PGP SIGNATURE-----
M.-A. Lemburg schrieb:
On 2008-05-27 12:56, Thomas Heller wrote:
M.-A. Lemburg schrieb:
On 2008-05-26 23:34, Christian Heimes wrote:
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
M.-A. Lemburg schrieb: 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.
There are applications out there that dynamically import the python dll and link to the exported functions by name; they will all break.
The exported APIs still use the old names. Just the source code versions of the APIs change to the new names and they now live in different files as well.
Sorry, then, I confused it with py3k. Thomas
participants (3)
-
Jesus Cea
-
M.-A. Lemburg
-
Thomas Heller