[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg report at bugs.python.org
Tue Aug 16 23:07:47 CEST 2011


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at 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.

Regarding separating adding the various surrogate macros and
the next-macros: I don't see a problem with adding both in
Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________


More information about the Python-bugs-list mailing list