[Nick]
> 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.
Is that use case strong enough to require the added complexity? For a
transactional wrapper, I can see that __exit__ needs to know about
exceptions (though I'm unsure how much detail it needs), but what's
the point of being able to tell an exception from a non-local goto
(which break, continue and return really are)? I could see the
following, minimal translation:
oke = False
abc = EXPR
var = abc.__enter__()
try:
BLOCK
oke = True
finally:
abc.__exit__(oke)
What's your use case for giving __enter__ an opportunity to skip the
block altogether?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4