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 ezio.melotti
Recipients Rhamphoryncus, amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, loewis, pitrou, rhettinger, vstinner
Date 2010-11-27.22:41:16
SpamBayes Score 2.2956916e-08
Marked as misclassified No
Message-id <1290897679.59.0.329536250931.issue10542@psf.upfronthosting.co.za>
In-reply-to
Content
> * 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).
 
> * 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 :-)

The term code point is not entirely correct here. High and low surrogates are code points too. The right term should be 'scalar value' (but that might be confusing). The 'READ' bit sounds fine though, maybe 'READ_NEXT'?
History
Date User Action Args
2010-11-27 22:41:19ezio.melottisetrecipients: + ezio.melotti, lemburg, loewis, rhettinger, amaury.forgeotdarc, belopolsky, Rhamphoryncus, pitrou, vstinner, eric.smith
2010-11-27 22:41:19ezio.melottisetmessageid: <1290897679.59.0.329536250931.issue10542@psf.upfronthosting.co.za>
2010-11-27 22:41:16ezio.melottilinkissue10542 messages
2010-11-27 22:41:16ezio.melotticreate