Mention some rejected ideas (and explain why).
This commit is contained in:
parent
fa5f960327
commit
87d2fd6de8
40
pep-0340.txt
40
pep-0340.txt
|
@ -373,12 +373,28 @@ Specification: Generator Exit Handling
|
|||
cases work differently; in Python, you cannot save the block for
|
||||
later use, and you cannot test whether there is a block or not.
|
||||
|
||||
Alternatives Considered
|
||||
Alternatives Considered and Rejected
|
||||
|
||||
- Many alternatives have been proposed for 'block', including '@'
|
||||
and no keyword at all. I haven't seen a proposal for another
|
||||
keyword that I like better than 'block' yet, and not using a
|
||||
keyword at all makes many folks (including me) uncomfortable.
|
||||
- Many alternatives have been proposed for 'block'. I haven't
|
||||
seen a proposal for another keyword that I like better than
|
||||
'block' yet. Alas, 'block' is also not a good choice; it is a
|
||||
rather popular name for variables, arguments and methods.
|
||||
Perhaps 'with' is the best choice after all?
|
||||
|
||||
- Instead of trying to pick the ideal keyword, the block-statement
|
||||
could simply have the form:
|
||||
|
||||
EXPR1 as VAR1:
|
||||
BLOCK1
|
||||
|
||||
This is at first attractive because, together with a good choice
|
||||
of function names (like those in the Examples section below)
|
||||
used in EXPR1, it reads well, and feels like a "user-defined
|
||||
statement". And yet, it makes me (and many others)
|
||||
uncomfortable; without a keyword the syntax is very "bland",
|
||||
difficult to look up in a manual (remember that 'as' is
|
||||
optional), and it makes the meaning of break and continue in the
|
||||
block-statement even more confusing.
|
||||
|
||||
- Phillip Eby has proposed to have the block-statement use
|
||||
an entirely different API than the for-loop, to differentiate
|
||||
|
@ -388,6 +404,20 @@ Alternatives Considered
|
|||
that the block-statement is conceptually a loop -- it supports
|
||||
break and continue, after all.
|
||||
|
||||
- This keeps getting proposed: "block VAR1 = EXPR1" instead of
|
||||
"block EXPR1 as VAR1". That would be very misleading, since
|
||||
VAR1 does *not* get assigned the value of EXPR1; EXPR1 results
|
||||
in a generator which is assigned to an internal variable, and
|
||||
VAR1 is the value returned by successive calls to the __next__()
|
||||
method of that iterator.
|
||||
|
||||
- Why not change the translation to apply iter(EXPR1)? All the
|
||||
examples would continue to work. But this makes the
|
||||
block-statement *more* like a for-loop, while the emphasis ought
|
||||
to be on the *difference* between the two. Not calling iter()
|
||||
catches a bunch of misunderstandings, like using a sequence as
|
||||
EXPR1.
|
||||
|
||||
Comparison to Thunks
|
||||
|
||||
Alternative semantics proposed for the block-statement turn the
|
||||
|
|
Loading…
Reference in New Issue