STINNER Victor <victor.stin...@haypocalc.com> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10542> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
