homepage

Alexander Belopolsky wrote:
> 
> Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment:
> 
> I am attaching a patch for commit review. I added an underscore prefix to all new macros. This way I am not introducing new features and we will have a full release cycle to come up with better names. i would just note that "next" terminology is consistent with PyDict_Next and _PySet_NextEntry. The latter suggests that Py_UNICODE_NEXT_UCS4 may be a better choice.
I don't think this should go into 3.2. The macros have the potential
of subtly changing Python semantics when used in places that previously
did not support auto-joining surrogates. Let's wait for 3.3 with the
change.
Some comments:
* The macros still need some more attention to enhance their performance.
* For consistency, I'd choose names Py_UNICODE_READ_NEXT()
 and Py_UNICODE_WRITE_NEXT() instead of Py_UNICODE_NEXT() and
 Py_UNICODE_PUT_NEXT().
* Py_UNICODE_JOIN_SURROGATES() either needs to go away completely
 (and be integrated straight into the other macros), or be renamed
 to Py_UCS4_JOIN_SURROGATES(), since it doesn't return Py_UNICODE
 values
* The macros need to be carefully documented, both in unicodeobject.h
 and the general docs.
* Your _Py_UNICODE_PUT_NEXT() implementation is missing a few casts
 to turn ch into a Py_UNICODE/Py_UCS4 value.
* Same for your _Py_UNICODE_NEXT() to make sure that the return
 value is indeed a Py_UNICODE value.
* In general, we should probably be clear on the allowed input
 and define the output types in the documentation.