[Python-Dev] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Guido]
> >The 'oke' argument is so that the author of transactional() can decide
> >what to do with a non-local goto: commit, rollback or hit the author
> >over the head with a big stick.

[Phillip J. Eby]
> Since this is just a replacement for a try/except/finally block, I'd expect
> that in a transactional case that a non-local goto would work the same as
> any other non-exception exit.
> 
> ISTM that the resource block use cases are:
> 
> * Save the current state of something, modify it, and then restore the old
> state once the block completes (try/finally, used for locking, redirection,
> signals, decimal context, etc.)
> 
> * Automatically roll back partially-done work in case of exception, and/or
> "roll forward" completed work (try/except/else, used for "transaction"
> scenarios)
> 
> * Release allocated resource(s) after use (try/finally, used to close files
> and suchlike)
> 
> None of these, AFAICT, benefit from differing behavior in the presence of
> nonlinear (but non-exceptional) control flow.  It just seems too magical to
> me in the new context.  When we were talking about a "block" construct or
> user-defined syntax, it made more sense because you could actually redefine
> the *meaning* of those constructs to some extent -- and because the
> *target* of the break and continue statements at least was the block
> itself, not some containing block.

That works for me; I was just hypothesizing about the needs of others,
but personally I'm fine with not knowing. I guess part of my
motivation is also that this information is readily available
intenally when a finally-clause is executed, since when the clause
completes a pending non-local goto has to be resumed. But there's no
reason to expose *all* internal state information...

So the signature of __exit__ is just what sys.exc_info() returns.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)