RetroSearch Browse

Wed Jun 11 10:52:06 CEST 2008 · https://mail.python.org/pipermail/python-dev/2008-June/080216.html

On 2008-06-11 05:42, Gregory P. Smith wrote:
> On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> 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).
>>
> 
> all done as of 64105

Thank you !

-- 
Marc-Andre Lemburg
eGenix.com

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-June/080216.html below:

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