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

[Thomas Heller]

M.-A. Lemburg schrieb:
> On 2008-05-26 23:34, Christian Heimes wrote:
>> 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.
> 
> 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.

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 .

Thomas