> > In contrast, the new use of yield differs in that the suspended
frame
> > transfers control from the encloser to the enclosed.
>
> Why does your notion of who encloses whom suddenly reverse when you go
> from a for-loop to a block-statement? This all feels very strange to
> me.
After another reading of the PEP, it seems fine.
On the earlier readings, the "yield" felt disorienting because the body
of the block is subordinate to the block-iterator yet its code is
co-located with the caller (albeit set-off with a colon and
indentation).
> I meant to use this as an example of the unsuitability of the
> @synchronized decorator, since it implies that all synchronization is
> on the same mutex, thereby providing a use case for the locking
> block-statement.
>
> I suspect we're violently in agreement though.
Right :-)
> > This is the strongest example so far. When adding it to the PEP, it
> > would be useful to contrast the code with simpler alternatives like
PEP
> > 288's g.throw() or PEP 325's g.close(). On the plus side, the
> > block-iterator approach factors out code common to multiple callers.
On
> > the minus side, the other PEPs involve simpler mechanisms and their
> > learning curve would be nearly zero. These pluses and minuses are
> > important because apply equally to all examples using blocks for
> > initialization/finalization.
>
> Where do you see a learning curve for blocks?
Altering the meaning of a for-loop; introducing a new keyword; extending
the semantics of "break" and "continue"; allowing try/finally inside a
generator; introducing new control flow; adding new magic methods
__next__ and __exit__; adding a new context for "as"; and tranforming
"yield" from statement semantics to expression semantics. This isn't a
lightweight proposal and not one where we get transference of knowledge
from other languages (except for a few users of Ruby, Smalltalk, etc).
By comparision, g.throw() or g.close() are trivially simple approaches
to generator/iterator finalization.
In section on new for-loop specification, what is the purpose of "arg"?
Can it be replaced with the constant None?
itr = iter(EXPR1)
brk = False
while True:
try:
VAR1 = next(itr, None)
except StopIteration:
brk = True
break
BLOCK1
if brk:
BLOCK2
In "block expr as var", can "var" be any lvalue?
block context() as inputfil, outputfil, errorfil:
for i, line in enumerate(inputfil):
if not checkformat(line):
print >> errorfil, line
else:
print >> outputfil, secret_recipe(line)
In re-reading the examples, it occurred to me that the word "block"
already has meaning in the context of threading.Lock.acquire() which has
an optional blocking argument defaulting to 1.
In example 4, consider adding a comment that the "continue" has its
normal (non-extending) meaning.
The examples should demonstrate the operation of the extended form of
"continue", "break", and "return" in the body of the block.
Raymond
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
