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

[Gregory P. Smith]

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.

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.


>
>
> 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.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080608/efa67dcf/attachment-0001.htm>