On 2008-06-09 07:20, Gregory P. Smith wrote:
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.
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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
