Author belopolsky
Recipients Rhamphoryncus, amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, loewis, pitrou, rhettinger, vstinner
Date 2010-11-27.23:20:04
SpamBayes Score 8.15378e-11
Marked as misclassified No
Message-id <AANLkTiktw31aoopWqHH=j0rG6Ad5nAUbMCtwkU5KK+yb@mail.gmail.com>
In-reply-to <1290897679.59.0.329536250931.issue10542@psf.upfronthosting.co.za>
Content
On Sat, Nov 27, 2010 at 5:41 PM, Ezio Melotti <report@bugs.python.org> wrote:
>
> Ezio Melotti <ezio.melotti@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.
History
Date User Action Args
2010-11-27 23:20:06belopolskysetrecipients: + belopolsky, lemburg, loewis, rhettinger, amaury.forgeotdarc, Rhamphoryncus, pitrou, vstinner, eric.smith, ezio.melotti
2010-11-27 23:20:04belopolskylinkissue10542 messages
2010-11-27 23:20:04belopolskycreate