[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