Author belopolsky
Recipients Rhamphoryncus, amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, loewis, pitrou, vstinner
Date 2010-11-27.02:52:54
SpamBayes Score 1.13598e-12
Marked as misclassified No
Message-id <AANLkTikW01z=Z+oOx9yp5D79YS_Uq18ZZ6R7pRXVWnHw@mail.gmail.com>
In-reply-to <1290824567.37.0.944451066017.issue10542@psf.upfronthosting.co.za>
Content
On Fri, Nov 26, 2010 at 9:22 PM, Eric Smith <report@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.
History
Date User Action Args
2010-11-27 02:52:56belopolskysetrecipients: + belopolsky, lemburg, loewis, amaury.forgeotdarc, Rhamphoryncus, pitrou, vstinner, eric.smith, ezio.melotti
2010-11-27 02:52:54belopolskylinkissue10542 messages
2010-11-27 02:52:54belopolskycreate