GeezerVison

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