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?
> 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.
> - The choice of a keyword. How about 'in'? ("in object: suite") > -
'in' is good. If Jim's system is goind to be used, it allows delayed or
concurrent execution of the suite. "in" implies immediate execution, so
"in" may be more confusing than "as" in that case. On the plus side, "in"
is already a python keyword.