[Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0
M.-A. Lemburg
mal at egenix.com
Mon Jun 9 10:44:38 CEST 2008
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
More information about the Python-3000
mailing list