[Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
Josiah Carlson
jcarlson at uci.edu
Tue Mar 6 00:56:11 CET 2007
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
More information about the Python-3000
mailing list