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.