Message142260
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. |
|
Date |
User |
Action |
Args |
2011-08-17 10:15:59 | vstinner | set | recipients:
+ vstinner, lemburg, loewis, doerwalter, georg.brandl, rhettinger, amaury.forgeotdarc, belopolsky, Rhamphoryncus, pitrou, eric.smith, stutzbach, ezio.melotti, tchrist |
2011-08-17 10:15:58 | vstinner | link | issue10542 messages |
2011-08-17 10:15:58 | vstinner | create | |
|