Add a section of loose ends.
This commit is contained in:
parent
885ebd643c
commit
b63ff845a3
38
pep-0340.txt
38
pep-0340.txt
|
@ -36,19 +36,19 @@ Proposal Evolution
|
|||
|
||||
The added twist is that instead of adding a flag argument to
|
||||
next() and __next__() to indicate whether the previous argument is
|
||||
a value or an exception, we use a separate API (an __error__()
|
||||
a value or an exception, we use a separate API (an __exit__()
|
||||
method taking an exception and perhaps a traceback) for the
|
||||
exception. If an iterator doesn't implement __error__(), the
|
||||
exception. If an iterator doesn't implement __exit__(), the
|
||||
exception is just re-raised. It is expected that, apart from
|
||||
generators, very few iterators will implement __error__(); one use
|
||||
generators, very few iterators will implement __exit__(); one use
|
||||
case would be a fast implementation of synchronized() written in
|
||||
C.
|
||||
|
||||
The built-in next() function only interfaces to the next() and
|
||||
__next__() methods; there is no user-friendly API to call
|
||||
__error__().
|
||||
|
||||
Perhaps __error__() should be named __exit__().
|
||||
__exit__(). (Or perhaps calling next(itr, exc, traceback) would
|
||||
call itr.__exit__(exc, traceback) if itr has an __exit__ method
|
||||
and otherwise raise exc.__class__, exc, traceback?)
|
||||
|
||||
Motivation and Summary
|
||||
|
||||
|
@ -432,6 +432,32 @@ Specification: Alternative __next__() and Generator Exception Handling
|
|||
EXPR2" is changed; break and return translate to themselves in
|
||||
that case).
|
||||
|
||||
Loose Ends
|
||||
|
||||
These are things that need to be resolved before accepting the
|
||||
PEP.
|
||||
|
||||
- Fill in the remaining TBD sections.
|
||||
|
||||
- Address Phillip Eby's proposal to have the block-statement use
|
||||
an entirely different API than the for-loop, to differentiate
|
||||
between the two (a generator would have to be wrapped in a
|
||||
decorator to make it support the block API).
|
||||
|
||||
- Decide on the keyword ('block', 'with', '@', nothing, or
|
||||
something else?).
|
||||
|
||||
- Phillip Eby wants a way to pass tracebacks along with
|
||||
exceptions.
|
||||
|
||||
- The translation for the for-loop's else-clause.
|
||||
|
||||
- Whether a block-statement should allow an else-clause.
|
||||
|
||||
- Which API to use to pass in an exception: itr.__next__(exc),
|
||||
itr.__next__(exc, True) or itr.__exit__(exc[, traceback]).
|
||||
Hmm..., perhaps itr.__next__(exc, traceback)?
|
||||
|
||||
Comparison to Thunks
|
||||
|
||||
Alternative semantics proposed for the block-statement turn the
|
||||
|
|
Loading…
Reference in New Issue