[Python-Dev] PEP 340: Only for try/finally?
bjourne at gmail.com
Tue May 3 23:54:45 CEST 2005
> > Guido> How many try/finally statements have you written inside a loop?
> > Guido> In my experience this is extreeeemely rare. I found no
> > Guido> occurrences in the standard library.
> [Skip again]
> > How'd we start talking about try/finally?
> Because it provides by far the dominant use case for 'block'. The
> block-statement is intended to replace many boilerplace uses of
> try/finally. In addition, it's also a coroutine invocation primitive.
Maybe I'm not understanding something, but why should "block" only be
for less boilerplate in try/finally's? I spent an hour grepping
through the standard library and there are indeed lots of use cases
for some blocks to replace try/finallys. There are opportunities for
block opening(file) and block locked(mutex) everywhere!
But why stop there? Lots of functions that takes a callable as
argument could be upgraded to use the new block syntax. Because it is
a cool way to do template method, isn't it? Take wrapper() in
curses/wrapper.py for example. Why have it like this:
wrapper(curses_wrapped_main) when you can have it like this:
. (main program stuff)
Or assertRaises in unittest.py, why call it like this:
self.assertRaises(TypeError, lambda: a*x)
When you can squash the lambda like this:
Or for another use case, in gl-code you often write glBegin()..
glDrawBlah().. glEnd(). Make it properly indented!:
.block glNowDraw(): # glBegin(); yield; glEnd()
Make your own repeat-until loop:
. while True:
. yield None
. if cond:
.block until(lambda: s == "quit"):
. s = sys.stdin.readline()
It seems like the possibilities are endless. Maybe too endless?
Because this new feature is so similar to anonymous functions, but is
not quite anonymous functions, so why not introduce anonymous
functions instead, that could make all the things block can, and more?
But as I said, I'm misunderstanding something.
More information about the Python-Dev