[Python-3000] PEP: rename it.next() to it.next(), add a next() built-in (original) (raw)
Josiah Carlson jcarlson at uci.edu
Tue Mar 6 00:56:11 CET 2007
- Previous message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Next message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Next message: [Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]