Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Fri, Nov 26, 2010 at 9:22 PM, Eric Smith <rep...@bugs.python.org> wrote: .. > But I definitely agree that we should get the abstraction right first and > worry about > the implementation later. I am fairly happy with Py_UNICODE_NEXT() abstraction. It's semantics should be natural for users familiar with python iterators and the fact that it expands to simply *ptr++ on wide builds makes it easy to explain its usage. I am note very happy about the end argument for the following reasons: 1. Builtin "next()" takes the default value as a second argument. Extension writers may expect the same from Py_UNICODE_NEXT(). The name "end" should be self-explainatory though, especially to those with an exposure to STL. 2. If Py_UNICODE_NEXT() stays as a macro, an innocent looking Py_UNICODE_NEXT(p, p + size) will have a hard to detect bug. Can be fixed by making Py_UNICODE_NEXT() a function. I wonder whether it is best to prefix the new macros with an underscore. On one hand, we want to make this available to extension writers, on the other hand, once more people start dealing with non-BMP issues, a better abstraction may be found and we man not want to maintain Py_UNICODE_NEXT() indefinitely. ---------- _______________________________________ 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
