On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> 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). > all done as of 64105
_______________________________________________ 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
