In article <JFULTON.95Feb1130947@disqvarsa.er.usgs.gov>,
Jim Fulton <jfulton@disqvarsa.er.usgs.GOV> wrote:
>
> >>>>> "Ty" == Ty Sarna <tsarna@endicor.com> writes:
> In article <D355o7.I83@endicor.com> tsarna@endicor.com (Ty Sarna)
> writes:
>
> > In article <9501281121.AA16443=guido@guppie.cwi.nl>,
> > <Guido.van.Rossum@cwi.nl> wrote:
>
> In my transaction model, there are THREE ways to exit:
>
> 1. Normal completion (need to commit)
> 2. Python exception (need to abort)
> 3. Transaction aborted by transaction processing system, independent
> of transaction code execution (already aborted).
OK. I considered this outside the scope of the transaction wrapper. I was
intending to handle that outside of the transaction block as a standard
exception.
> Other applications may have different requirements. I'd like to see
> an approach that works for many different applications.
Ditto. I'm not wedded to my scheme. Yours can do what I want (and more,
like a cleaner syntax for threads), so I'd be happy to go with it. I do
agree with Guido that "exec" may not be the best keyword. I think "enter"
is better, but it applies better to my model than yours. I sort of like
"with", but it could be confusing to those who are familiar with that
keyword's totally different use in Pascal.
Actually, how about "as"? As in "execute this code as a transaction (or
thread, or whatever). "as transaction: ....", "as thread:", etc. Anyone?
> This approach is different from what I proposed. In my proposal, a
> callable object (e.g. a function) is given the code to execute. Your
> approach uses two functions (methods of transaction objects) that
> setup for and then wrap up after a transaction has been executed. You
> have no control over when or if the code is executed. In your
> proposal, what happens if an exception is raised in the __enter__
> function?
Right... mine was a cross between Guido's and your ideas.
In my model, an exception in __enter__ would be handled in the same scope
as the "enter". If I wanted to handle it there, I'd do it in a
try:...except:... enclosing the enter:...
> at all. My approach allows applications like:
>
> exec thread:
> ...some code that is executed in a separate thread...
Actually, I really like this, I think it's worth going with your model
for just this alone. The single biggest problem with programming threads
is lousy syntaxes, IMHO. If a new threads interface was written around
this kind of syntax it'd be a major win. Envison the standard textbook
producer-consumer relationship written that was vs. the old way and how
much clearer it would be.
Ty