Phillip J. Eby wrote:
> Specifically, I propose that PEP 340 *not* allow the use of "normal"
> iterators. Instead, the __next__ and __exit__ methods would be an
> unrelated protocol. This would eliminate the need for a 'next()'
> builtin,
> and avoid any confusion between today's iterators and a template
> function
> for use with blocks.
PEP 340 does not address "normal" iterators very well, but a
properly-constructed iterator will behave correctly.
The PEP though is very generator-focussed. The issues I see for "normal"
iterators (and that need to be addressed/stated in the PEP) are:
1. No automatic handling of parameters passed to __next__ and
__exit__.
In a generator, these will raise at the yield-statement or
-expression.
A "normal" iterator will have to take care of this manually.
This could be an argument to only allow generator-iterators to be used
with PEP 340 semantics (i.e. continue <EXPR>, block), but I don't think
it's a very compelling one.
Although perhaps the initial implementation could be restricted to
generator-iterators. So if a for-loop used `continue <EXPR>` it would
have a check (at the start of the for loop) that the iterator is a
generator-iterator. Likewise, a block-statement would always include
this check.
As another option, it might be worthwhile creating a base iterator type
with "correct" semantics.
Tim Delaney
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4