Author vstinner
Recipients Rhamphoryncus, amaury.forgeotdarc, belopolsky, doerwalter, eric.smith, ezio.melotti, georg.brandl, lemburg, loewis, pitrou, rhettinger, stutzbach, tchrist, vstinner
Date 2011-08-17.10:15:58
SpamBayes Score 1.89999e-10
Marked as misclassified No
Message-id <4E4B94DB.4090601@haypocalc.com>
In-reply-to <1313575689.69.0.748445535815.issue10542@psf.upfronthosting.co.za>
Content
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.
History
Date User Action Args
2011-08-17 10:15:59vstinnersetrecipients: + vstinner, lemburg, loewis, doerwalter, georg.brandl, rhettinger, amaury.forgeotdarc, belopolsky, Rhamphoryncus, pitrou, eric.smith, stutzbach, ezio.melotti, tchrist
2011-08-17 10:15:58vstinnerlinkissue10542 messages
2011-08-17 10:15:58vstinnercreate