[issue10542] Py_UNICODE_NEXT and other macros for surrogates
STINNER Victor
report at bugs.python.org
Wed Aug 17 12:15:59 CEST 2011
STINNER Victor <victor.stinner at haypocalc.com> added the comment:
Ah yes, the correct prefix for functions working on Py_UNICODE
characters/strings is "Py_UNICODE", not "PyUNICODE", sorry.
>> For Python 2.7 and 3.2, I would prefer to not touch a public header,
>> and so add the macros in unicodeobject.c.
>
> Is there some reason for this?
We don't add new features to stable releases.
>> If you want to make my HIGH_SURROGATE and LOW_SURROGATE macros
>> public, they will use to substract 0x10000 themself (whereas my
>> macros require the ordinal to be preproceed).
>
> If they turn out to be useful and we find a clearer name we can even make them public in 3.3, but we'll have to see about that.
I don't think that they are useful outside unicodeobject.c.
>> Note: I don't think that _Py_UNICODE*NEXT should go into
>> Python 2.7 or 3.2.
>
> If they don't it won't be possible to fix #9200 in those branches
I don't think that #9200 is a bug, but more a feature request.
> Not sure if it's better to check if it's a BMP char, or if it's not.
I prefer a shorter name and avoiding double negation:
!Py_UNICODE_IS_NON_BMP(ch).
> What are the naming convention for private macros in the same .c file where they are used?
Hopefully, there is no convention for private macros :-)
> Shouldn't they get at least a trailing _?
Nope.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________
More information about the Python-bugs-list
mailing list