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

[M.-A. Lemburg]

On 2008-06-09 07:20, Gregory P. Smith wrote:
> On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> On 2008-06-03 01:29, Gregory P. Smith wrote:
>>
>>> On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <guido at python.org>
>>> wrote:
>>>
>>>  I will freely admit that I haven't followed this thread in any detail,
>>>> but if it were up to me, I'd have the 2.6 internal code use PyString
>>>>
>>> ...
>>>
>>> Should we read this as a BDFL pronouncement and make it so?
>>>
>>> All that would mean change wise is that trunk r63675 as well as possibly
>>> r63672 and r63677 would need to be rolled back and this whole discussion
>>> over if such a big change should have happened would turn into a moot
>>> point.
>>>
>> I would certainly welcome reverting the change.
>>
>> All that's needed to support PyBytes API in 2.x is a set of #defines
>> that map the new APIs to the PyString names. That's a clean and
>> easily understandable solution.
>>
> 
> Okay, I've reverted r63675 in trunk revision r64048.  That leaves all of the
> python modules and internals using PyString_ api names instead of PyBytes_
> api names as they were before.  PyBytes_ #define's exist for the appropriate
> PyString methods incase anyone wants to use those.

Thanks.

> Programmers interested in the code
>> for a PyString API can then still look up the code in stringobject.c,
>> e.g. to find out how a certain special case is handled or to check
>> the ref counting - just like they did for years.
> 
> 
> The files still exist with the new names.  bytesobject.c instead of
> stringobject.c.  Those renames were done in the other CLs i mentioned which
> have not yet been reverted.  The current state seems a bit odd because they
> depend on the #defines to cause method definitions to be the PyString_ names
> instead of the PyBytes_ names.

Please restore the original state, ie. PyString APIs live in
stringobject.h and stringobject.c. bytesobject.h should then have
the #defines for PyBytes APIs, pointing them to the PyString
names (basically what's currently in stringobject.h).

>> Developer who want to start differentiating between mixed byte/text
>> data and bytes-only can start using PyBytes for byte data.
>>
>>  I would also add macros that map the PyBytes_* APIs to PyString_*, but
>>>> I would not start using these internally except in code newly written
>>>> for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString
>>>> for 8-bit strings containing text, and PyBytes for 8-bit strings
>>>> containing binary data. For 8-bit strings that could contain either
>>>> text or data, I'd use PyString, in the spirit of 2.x.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 09 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            27 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