Author lemburg
Recipients Rhamphoryncus, amaury.forgeotdarc, belopolsky, doerwalter, eric.smith, ezio.melotti, georg.brandl, lemburg, loewis, pitrou, rhettinger, stutzbach, tchrist, vstinner
Date 2011-08-16.21:12:48
SpamBayes Score 6.89524e-10
Marked as misclassified No
Message-id <4E4ADD4B.8080205@egenix.com>
In-reply-to <4E4ADC1E.80704@egenix.com>
Content
Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal@egenix.com> added the comment:
> 
> STINNER Victor wrote:
>>
>> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
>>
>> I'm reposting my patch from #12751. I think that it's simpler than belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private macros in unicodeobject.c to factorize the code.
>>
>> I don't want to add public macros because with the stable API and with the PEP 393, we are trying to hide the Py_UNICODE type and PyUnicodeObject internals. In belopolsky's patch, only Py_UNICODE_NEXT() is used outside unicodeobject.c.
> 
> PEP 393 is an optional feature for extension writers. If they don't
> need PEP 393 style stable ABIs and want to use the macros, they
> should be able to. I'm therefore -1 on making them private.

Sorry, I mean PEP 384, not PEP 393. Whether PEP 393 will turn out
to be a workable solution has yet to be seen, but that's a
different subject. In any case, Py_UNICODE and access macros
for PyUnicodeObject are in wide-spread use, so trying to hide
them won't work until we reach Py4k.

> Regarding separating adding the various surrogate macros and
> the next-macros: I don't see a problem with adding both in
> Python 3.3.
History
Date User Action Args
2011-08-16 21:12:49lemburgsetrecipients: + lemburg, loewis, doerwalter, georg.brandl, rhettinger, amaury.forgeotdarc, belopolsky, Rhamphoryncus, pitrou, vstinner, eric.smith, stutzbach, ezio.melotti, tchrist
2011-08-16 21:12:48lemburglinkissue10542 messages
2011-08-16 21:12:48lemburgcreate