> Jim sees additional uses for his proposal which would require the code
> objects. For example, it's not possible to implement thread or callback
> syntax with mine (at least that I can see).
>
> I don't know wether he needs code objects for his transaction system or
> not -- I don't understand what he's doing well enough. I do think a better
> syntax for callbacks and threads is a worthwhile goal, so it may well be
> worth doing it his way just for those reasons alone. In fact, I think I'd
> rather have his system than mine, for those reasons. This is getting over
> my head, though -- is there a way to implement threads and callback with
> my proposal somehow?
No, the use of code objects is absolutely not allowed. They are an
alien concept in the definition of Python (the *language*) right now,
and if they were to be used, they would have to be used consistently
in other parts of the language as well. I agree that it would be nice
to have these addditional features but they are not required for
implementing Jim's transaction processing. Maybe this is something
for a much bigger overhaul of the language's guts, some time...
> > A simplicfication could be to just call object() and _tmp(...) rahter
> > than __enter__ and __leave__ methods.
>
> My gut reaction is that it's better to call the methods than the objects.
Thanks, I agree.
Jim Fulton:
> I would like to have something similar, but I can live without it.
> It would be useful for some applications (other than TP) to be able to
> control when (and even if) the suite is executed. When I first
> suggested this, my thought that, to justify changing the language,
> the mechansism should be very general. My thought was to give a way
> to implement almost any sort of application-defined control
> structures.
But surely for that you would also have to have a way of introducing
arbitrary syntax -- there's no reason why an application defined
control structure would only require a single block. Again, let's put
this sideline to rest until there's time for some later time. (For
this reason I don't reply to subsequent remarks about the virtues of
code objects).
And in a later message:
> Drats, I spoke too quickly. I see a problem with 1. Consider the
> following __enter__:
>
> def __enter__(self):
> try:
> self.begin()
> except:
> self.abort()
>
> Suppose an interrupt causes an exception to be raised just after
> executing the try statement. __leave__ will not be called and the
> transaction created in the above try statement will not be aborted.
>
> I think that __enter__ and suite need to be treated as a unit and that
> __leave__ should be called even if an exception is raised in
> __enter__. Is it possible for an exception to be raised *between* the
> call to __enter__ and the execution of suite?
This is indeed a problem, and this is why I proposed to let __enter__
return an object whose __leave__ method is to be called. The object
returned can then have a destructor (__del__ method) which aborts thr
transaction if it has neither been committed nor aborted.
Don't similar race conditions exist in your original proposal?
--Guido van Rossum, CWI, Amsterdam <mailto:Guido.van.Rossum@cwi.nl>
<http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>