>> OK, I guess I'd still like to avoid these subtleties if possible.
>> Always calling __leave__ seems a lot simpler to me.
> 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.
What about exceptions that are raised after Transaction() runs but
before calling __enter__?
> 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!
Yes.
>> 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.
Right, but timing is usually not so critical. In most cases, __del__
frees resources and it is not so critical *when* it frees the
resources. In fact, one could choose to wait until the resource is
exhausted before doing the GC.
With transactions, the timing (or more specifically the order) of
transaction completion is critical.
Jim
--
-- Jim Fulton jfulton@mailqvarsa.er.usgs.gov (703) 648-5622
U.S. Geological Survey, Reston VA 22092
This message is being posted to obtain or provide technical information
relating to my duties at the U.S. Geological Survey.