[Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in

[Josiah Carlson]

Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
> Georg Brandl wrote:
> 
> > Indeed, you almost always have to have a try-except StopIteration-
> > wrapper around "manual" calls to .next().

The use-cases would likely be analagous to the .find() vs. .index()
methods on strings.

Then again, while I preferred .find() on strings, I don't mind catching
StopIteration in .next() - probably because I do far more string
manipulations than I do iterator manipulations, so I'm not bitten as
much by the annoyance of having to try/except StopIteration.

What about just adding a global next() (or operator.next()) and not
renaming the current .next() methods to __next__()?  It wouldn't be
consistant with other builtins that do automatic dispatch to __magic__
methods, but then the 2to3 translator wouldn't even need to get involved
(and potentially muck up non-method .next instance attributes, xnext = x.next
method or value caching, etc.).


> An alternative way of addressing this would be to
> have a new control structure. We already have the
> 'for' statement for when you want all the values;
> why not another one for when you just want one
> value? Maybe something like
> 
>    get item from iter:
>      # code for when we got something
>    else:
>      # code for when we didn't get anything

It's already spelled...

    for item in iter:
        #code for when we got something
        break
    else:
        #code for when we didn't get anything

 - Josiah