Re: Jim Fulton : Extensible compound statements -- new exec flavor

Guido.van.Rossum@cwi.nl
Sat, 28 Jan 1995 12:21:55 +0100

Jim Fulton asked my opinion about his proposal for a "transaction"
statement. I'd like to see this discussion back in public (I sort
of missed the first round) so I'm cc'ing my reply to the list, but I'm
not quoting Jim's material -- you can look it up in the mailing list
archives if you need to <URL:http://www.cwi.nl/~guido/hypermail/>.
(If Jim thinks parts are unclear he can post his own message to the
list or add it to his reply to this one.)

My first impression: yes, I've always been thinging about a syntactic
form that makes it possible to cleanly define things like
transactions, critical sections etc. We have try-finally (which is
*different* from try-except -- the two cannot be merged in one try
statment), but it has a race condition unless used very carefully.

If you put the begin-transaction operation inside the try suite, like
this:

try:
T.begin()
...code...
finally:
T.end()

there's a possibility that if it fails the end-transaction will find
the transaction not yet begun; if you put it outside the try clause,
like this:

T.begin()
try:
...code...
finally:
T.end()

then a KeyboardInterrupt or other asynchronous signal may arrive
before the try-finally is set up. It is also somewhat verbose to use.
I had been thinking along the lines of:

locking object:
suite

which would be equivalent, except for the fixed race condition, to:

object.__lock__()
try:
suite
finally:
object.__unlock__()

I'm not sure whether this has the same power of your proposal, since
you're a little weak on explaining the semantics.

I don't like hijacking the exec keyword for this. The exec statement
is intended to execute dynamically constructed code and you'r using it
for Something Completely Different (TM). I'm not so happy with
"lock" as a keyword either, but I think that if we want an addition
like this to the language it warrants inventing good, clean syntax for
it. As you point out it has much potential.

I'm not sure of the purpose of the "else" clause in your proposal, but
this may be because I also don't understand why you want the code for
the suites packed up and passed to your transaction object. What's
the purpose of this?

Finally I'm not sure if you grasp the power of try-finally, since your
examples are all phrased in terms of try-except, sometimes with a
unqualified except that re-raises the original exception after some
clean-up. This is what try-finally is for!

That's gotta be all for today (there's beer to be bought, and a party
to be prepared!),

--Guido van Rossum, CWI, Amsterdam <mailto:Guido.van.Rossum@cwi.nl>
<http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>