On 4/25/05, Tim Delaney <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > but for backwards compatibility with the existing argument-less next()
> > API I'm introducing a new iterator API next_ex() which takes an
> > exception argument. If that argument is None, it should behave just
> > like next(). Otherwise, if the iterator is a generator, this will
>
> Might this be a good time to introduce __next__ (having the same signature
> and semantics as your proposed next_ex) and builtin next(obj,
> exception=None)?
>
> def next(obj, exception=None):
>
> if hasattr(obj, '__next__'):
> return obj.__next__(exception)
>
> if exception is not None:
> return obj.next(exception) # Will raise an appropriate exception
>
> return obj.next()
Hmm, it took me a while to get this, but what you're ssaying is that
if you modify Guido's "what I really want" solution to use
VAR = next(it, exc)
then this builtin next makes "API v2" stuff using __next__ work while
remaining backward compatible with old-style "API v1" stuff using
0-arg next() (as long as old-style stuff isn't used in a context where
an exception gets passed back in).
I'd suggest that the new builtin have a "magic" name (__next__ being
the obvious one :-)) to make it clear that it's an internal
implementation detail.
Paul.
PS The first person to replace builtin __next__ in order to implement
a "next hook" of some sort, gets shot :-)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
