[Python-checkins] r63672 - in python/trunk: Include/Python.h Include/bytearrayobject.h Include/bytesobject.h Include/pythonrun.h Include/stringobject.h Objects/bytesobject.c Objects/object.c Objects/stringobject.c Objects/unicodeobject.c Python/bltinmodule.c Python/pythonrun.c

[Nick Coghlan]

M.-A. Lemburg wrote:
> On 2008-05-26 14:29, christian.heimes wrote:
>> Author: christian.heimes
>> Date: Mon May 26 14:29:14 2008
>> New Revision: 63672
>>
>> Log:
>> First step of the C API rename:
>> renamed Include/bytesobject.h to Include/bytearrayobject.h
>> renamed Include/stringobject.h to Include/bytesobject.h
>> added Include/stringobject.h with aliases
> 
> I think you have those aliases backwards:

Looking at the NEWS entry, I can sort of see the reason for doing it 
this way -  defining the macros that way around makes the names that are 
visible to the linker are the old PyString names rather than the new 
PyBytes names.

stringobject.h could probably use a prominent comment explaining the 
benefits of doing it this way though. Since people are going to have to 
recompile their modules anyway for the new 2.6 release, what gain is 
there really in keeping the PyString_* names as the ones that are 
visible to the linker? Recompiling the extensions is necessarily going 
to involve relinking them as well, so picking up the new names being 
exported by Python binary shouldn't be an issue.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org