[issue10542] Py_UNICODE_NEXT and other macros for surrogates

[Alexander Belopolsky]

Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Nov 27, 2010 at 5:41 PM, Ezio Melotti <report at bugs.python.org> wrote:
>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
>> * the Py_UNICODE_JOIN_SURROGATES() macro should use Py_UCS4 as prefix since it returns Py_UCS4 values, i.e. Py_UCS4_JOIN_SURROGATES()
>> * same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()
>
> I'm not so familiar with the prefix conventions, but wouldn't that lead users to think that this macro is for wide builds and that they have to use Py_UCS2_* macros for narrow builds? If these macros are supposed to abstract the build type maybe they should have a "neutral" prefix. (But if the conventions we use say otherwise I guess the best we can do is to document it properly).

When I was using the name, I did not think about argument type.
Py_UNICODE_ is just the namespace prefix used by all macros in
unicodeobject.h. Case in point: Py_UNICODE_ISALPHA() and family that
take Py_UCS4.  (I know, there is a historical reason at work here, but
why fight it?)

Functions use PyUnicode_ prefix and build specific functions use
PyUnicodeUCSx_ prefix.   As far as I can tell, there are no macros
with Py_UCS4_ prefix.  The choices I like in the order of preference
are

1. Py_UNICODE_NEXT
2. Py_UNICODE_NEXT_UCS4
3. Py_UNICODE_READ_NEXT_UCS4

I can live with anything else, though.

----------

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