OK, it's your call.
BTW I think the following would also work:
def Transaction():
try:
<do stuff>
return <transaction-object>
except:
<recover from error or interrupt>
i.e. put the return inside a try-except. Then there is no point in
the code where an asynchronous exception is uncaught. BTW, I also
like Marc Wachowitz' suggestion to use the new 'in' statement to
delineate sections of code where interrupts should be delayed. Very
elegant!
> At the Python workshop, there was some discussion of alternate GC
> strategies. Do you really want to commit to current GC semantics now?
> I spent some time on the ANSI Smalltalk committee and the vendors on
> that committee were extremely unwilling to commit to particular GC
> semantics. In fact, they did not (at the time) want to even guarantee
> that an ANSI Smalltalk system would actually do garbage collection at
> all. On the other hand, Smalltalk does not use destructors, so the
> execution of finallization code is not an issue. Still, might not
> future implementations of Python want to use less deterministic GCs?
> Would committing to the current GC timing semantics prevent
> implementation of reference following garbage collectors in the
> future?
Good point. Unfortunately Python currently already has __del__, and
also much working code relies on the fact that files opened in the
local scope are closed automatically when the variable becomes
inaccessible, etc. -- this is needed otherwise programs that open lots
of files in a loop will run out of file descriptors, etc. Similar for
window objects. So Python, like C++, will always require support for
finalization from whatever GC strategy is chosen.
(I remember a message from Bill Janssen announcing a malloc-replacing
GC with finalization support -- anyone got time to look into that?)
--Guido van Rossum, CWI, Amsterdam <mailto:Guido.van.Rossum@cwi.nl>
<http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>