[Python-Dev] exec/with thunk-handling proposal

[Michael Hudson]

holger krekel <pyth@devel.trillke.net> writes:

> Michael Hudson wrote:
>> holger krekel <pyth@devel.trillke.net> writes:
>> > I think we can may get away with only a "weak" keyword
>> > and allow the aforementioned encapsulation of execution 
>> > events into an object like this:
>> >
>> >     exec expr [with params]: suite
>> 
>> Gut reaction: ugh!
>
> then i guess you rather prefer new keywords.  I thought that there
> is a general reluctance to introduce new keywords

There is.  But __future__ makes a sensible transition possible, at least.

> *and* many people dislike 'exec' for its existence.  So reusing it
> (and we are dealing with execution aspects IMO) makes some sense to
> me.

It makes some sense, sure.  But not enough, in *my* opinion.

We don't want to go down the C route -- consider poor "static"[1].

[...]
>> > The above "with" parameters (of the form name=expr, comma-separated) 
>> > are bound in local (or global/nested) *and* handler instance 
>> > namespace.  The 'suite' is what we call "thunk".
>> >
>> > The above logic allows clean timely finalization for
>> > *multiple* ressources:
>> >
>> >     exec autoclose() with f1=open(name1), f2=open(name2, 'w'):
>> >         for line in f1:
>> >             ...
>> >             f2.write(...)
>> 
>> That looks messy.
>
> as compared to?  I think i have seen messier ideas with all kinds
> of brackets and double-colons :-)

As compared to the dirt simple scheme Paul just posted about.

>> > which would execute as follows
>> >
>> >     a) autoclose() instance is created and stored as the 
>> >        "thunk"-handler
>> 
>> We need a name for these.  I've been using "monitor" for a while, but
>> I'm not sure it's that apposite.
>
> So far i'd liked "execution handler" because 'enter/exit/except' are IMHO
> execution events which you can hook into.  Do you agree with calling
> them 'execution events' or how would you call them?

Sure enter/exit/except are execution events, but execution handler
rubs me the wrong way because that imples the (e.g.) autoclose object
is somehow responsible for executing the suite, which it isn't: it;s
more an observer of the execution.

And it's a suite goddamit, not a thunk (in this proposal).

>> >     b) f1/f2 are stored as attributes on the autoclose instance
>> >
>> >     c) f1/f2 are put into the local/global namespace (and nested ones
>> >        if rebinding is allowed)
>> >
>> >     d) thunk executes (for line ...)
>> >
>> >     e) autoclose 'leave' hook is called (with or without exception)
>> >        and is implemented like this:
>> >         
>> >        def __leave__(self):
>> >             for obj in self.__dict__.values(): 
>> >                 obj.close()
>> >
>> >     f) thunk handler is removed 
>> 
>> "Too much magic!"
>
> Hmmm. That seems a bit unfair to me as many other proposals didn't care 
> to elaborate the exact sequence.

True.  However, I'm currently in favour of a very simple proposal.

> You probably are refering to the "namespace interactions" as the
> other stuff is probably the same with any other proposal so far.

I'd very much hope that some of the sillier proposal are dead in the
water.  Sure, your proposal is hardly the most complex out there, but
*I* still think it's too complex.

Actually, it's mainly the b) and c) bits I object to.

>> > Because computing 'f1' may succeed but 'f2' can subsequently
>> > fail the assignments *have to* execute within "autoclose"
>> > control.  
>
> Would the following be the correct way to achieve this with your patch? 
>
>     f1=open(inputfn)
>     with autoclose(f1):
>         f2 = open(outputfn, 'w')
>         with autoclose(f2):
>             for line in f1:
>                 ...
>                 f2.write(line)

Yup.

> I think there should be a better solution for multiple ressources.

Fair enough.  I don't.

[...]

>> I am *still* not convinced that an __except__ hook is worth the pain.
>> Can you implement those for me?
>
> Maybe, i haven't looked at your implementation yet and there are
> some other projects pending :-)

I meant, can you implement retry and skip_on?  Sorry, that was
unclear.

[...]
>> Would you propose calling the __enter__ method each time the generator
>> resumed?
>
> yes, neccessary for locking (as the above example tried to indicate).

Hmm, that could work.  Tricky to implement as things currently stand
but managable for sure.

Good grief, I should do something useful today.

Cheers,
M.

[1] Strange small worldy fact: the phrase "consider poor static" has
    stuck with from my earliest usenet experiences, so I google for
    it, and it turns out it was John W. Baxter, comp.lang.python
    regular.

-- 
  : Giant screaming pieces of excrement, they are.
  I have a feeling that some of the people in here have a 
  MUCH more exciting time relieving themselves than I do.
                                       -- Mike Sphar & Dave Brown, asr