[Python-Dev] Merging PEP 310 and PEP 340-redux?
Nick Coghlan
ncoghlan at gmail.com
Tue May 10 11:18:36 CEST 2005
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 | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
More information about the Python-Dev
mailing list