[Python-checkins] python/nondist/peps pep-0340.txt,1.23,1.24
gvanrossum@users.sourceforge.net
gvanrossum at users.sourceforge.net
Thu May 5 17:39:21 CEST 2005
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25281
Modified Files:
pep-0340.txt
Log Message:
Mention some rejected ideas (and explain why).
Index: pep-0340.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0340.txt,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -d -r1.23 -r1.24
--- pep-0340.txt 4 May 2005 21:00:46 -0000 1.23
+++ pep-0340.txt 5 May 2005 15:39:19 -0000 1.24
@@ -373,12 +373,28 @@
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 @@
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
More information about the Python-checkins
mailing list