[Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0 (original) (raw)

Gregory P. Smith greg at krypto.org
Mon Jun 9 07:20:36 CEST 2008

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>

More information about the Python-Dev mailing list