On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-06-03 01:29, Gregory P. Smith wrote: > >> On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> >> 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. >>> >> >
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
