> > 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: .block wrapper(): . (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: .block self.assertRaises(TypeError): . a*x Or for another use case, in gl-code you often write glBegin().. glDrawBlah().. glEnd(). Make it properly indented!: .block glNowDraw(): # glBegin(); yield; glEnd() . glDrawBlah() Make your own repeat-until loop: .def until(cond): . while True: . yield None . if cond: . break .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. -- mvh Björn _______________________________________________ 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
