GeezerVison

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