Guido van Rossum wrote: > Apologies if this has been discovered and rejected already; I've had > to skip most of the discussions but this though won't leave my head... > > So PEP 310 proposes this: > > with VAR = EXPR: > BLOCK > > translated to > > VAR = EXPR\ > if hasattr(VAR, "__enter__"): > VAR.__enter__() > try: > BLOCK > finally: > VAR.__exit__() > > I used to dislike this, but the opposition and the proliferation of > alternative proposals have made me realize that I'd rather have this > (plus "continue EXPR" which will be moved to a separate PEP once I > have some extra time) than most of the other proposals.
The User Defined Statement section of my PEP redraft suggests something very similar to this: http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html It suggests more complex semantics, so that the statement template has the chance to intercept exceptions raised in the block, and can tell the difference between normal termination and exiting the block via break, continue or return statements. This is needed to support some of the use cases (like the transaction() template). All of the PEP 340 examples are written up at the end of the PEP redraft, along with some of the motivating cases for a non-looping construct. (Ignore the part in the redraft about for loops for the moment - Greg Ewing has convinced me that what I currently have gets the default behaviour backwards. And, in relation to that, the next version will require a decorator to enable __enter__() and __exit__() methods on a given generator). Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com _______________________________________________ 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
