On 2008-05-26 15:40, Christian Heimes wrote:
M.-A. Lemburg schrieb:
Most imports will fail anyway at the link stage, since PyString_* APIs are probably the most used C APIs in Python extensions.
I think you have missed an important point. In Python 2.6 the names stay the same for the linker. Although the functions are now called PyBytes_Egg, they are redefined to PyString_Egg by a second header file.
In Python 2.6 the renaming of PyString are purely for consistence with the new Python 3.0 names. The names for PyString stay the same for external code like the library and extension modules.
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. You'd have to add an aliase bytes -> str to the builtins to at least reduce the confusion a bit. However, that's bound to cause even more problems, since people will start using bytes() instead of str() in Py2 applications and as a result they won't run in older Python versions anymore. The same problem applies to Py2 extensions writers that wish to support older Python releases as well.
PyBytes -> PyByteArray is a different story, though.
PyBytes was new in 2.6 anyway, so there's no breakage there.
One detail, I'm worried about is the change of the type name, since that is sometimes used in object serialization or proxy implementations.
The type names aren't changed, too They are still "str" and "bytearray" in Python 2.6
Good.
(moved down)
Since this is major break in the Python C API, please make sure that you bump the Python C API level used for module imports.
Do you still think it's necessary to bump up the C API version level?
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. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 26 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 41 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