This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Rhamphoryncus, amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, loewis, pitrou, rhettinger, vstinner
Date 2010-11-27.22:24:38
SpamBayes Score 6.543032e-08
Marked as misclassified No
Message-id <4CF18525.1050103@egenix.com>
In-reply-to <AANLkTinOHNDpk5qAUqDL16p_cxMAcFM0FvEL45ZHYEA0@mail.gmail.com>
Content
Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment:
> 
> On Sat, Nov 27, 2010 at 5:03 PM, Marc-Andre Lemburg
> <report@bugs.python.org> wrote:
> ..
>>  * same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()
>>
>>  * in order to make the macro easier to understand, please rename it to
>>  Py_UCS4_READ_CODE_POINT(); that's a little more typing, but still
>>  a lot less than without the macro :-)
> 
> I am not sure Py_UCS4_ prefix is right here.  (I agree on *SURROGATE*
> methods.)  The point of Py_UNICODE_NEXT(ptr, end) is that the pointers
> ptr and end are Py_UNICODE* and the macro expands to *p++ on wide
> builds.  Maybe Py_UNICODE_NEXT_USC4?

The idea is that the first part refers to what the macro returns (Py_UCS4)
and the "read" part of the name refers to moving a pointer across
an array (any array of integers).

Note that the macro can also work on Py_UCS4 arrays (even in
UCS2 builds), so it's universal in that respect.

Perhaps we should allow ord() to work on surrogates in
UCS4 builds as well. That would reduce the number of
surprises.
History
Date User Action Args
2010-11-27 22:24:39lemburgsetrecipients: + lemburg, loewis, rhettinger, amaury.forgeotdarc, belopolsky, Rhamphoryncus, pitrou, vstinner, eric.smith, ezio.melotti
2010-11-27 22:24:38lemburglinkissue10542 messages
2010-11-27 22:24:38lemburgcreate