[Python-Dev] Stabilizing the C API of 2.6 and 3.0

[Christian Heimes]

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.

I find the approach less confusing than your suggestion and my initial
idea. 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.

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.

> 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.

Christian