PEP 310 suggestions

[Michael Hudson]

Ben <ben at transversal.com> writes:

> I hope its not too late to make these comments as I know the PEP has been
> around for a while!

No, no hurry at present.  Posting to comp.lang.python isn't
necessarily the best way of making comments if you want me to read
them, but, hey, it's worked this time...

> While I was reading the PEP a few ideas popped into my head and I wondered
> if something like them had already been considered. They are probably
> rubbish, but I thought I would throw them into the mix!
> 
> 1) If Python had code blocks, 

If Python had code blocks it would be a different language (as you say
below).  PEP 310 arose out of a vast (at least 1000 posts) discussion
on python-dev, and is deliberately conservative.  Perhaps I should
mention this in the PEP...

> something like this would be possible
> 
> def open_file(file, code_block):
>   try:
>         code_block()
>   finally:
>         file.close()
> 
> then,
> 
> f = file("foo")
> with open_file(f):     #Note only passing one argument
>   # do stuff with f
> 
> This would only work if the code_block could be executed in the scope in
> which it was written, and not in the one in which it was called. 
> 
> This seems to be more general than the current PEP, but introduces quite
> massive changes into the language. The idea is that:
> 
> with func(args):
>         suite
> 
> goes to
> 
> func(args, suite)

"That's my PEP, you go get your own!" (with apologies to Shrek).

I don't want to get into a huge discussion of this sort of feature,
but I don't want to stop you getting into one either.  But I think it
belongs in a different PEP (you seem to have a decent start here!).

> 2) Exit handler blocks. These are kind to backwards try-finally blocks that
> allow the "close" function to be written close to the "open" one. They also
> have the advantage that no extra special functions are needed.
> 
> e.g
> 
> l = lock.aquire()
> onexit l.release():
>   # do stuff while locked
> 
> is eqivalent to
> 
> l = lock.aquire()
> try:
>    # do stuff while locked
> finally:
>    l.release()
> 
> The obvious disadvantage is that it may be non-obvious that the release call
> is delayed to the end of the block

Hmm, that's an idea I hadn't had.  Limiting the "on exit" code to just
one expression and the disadvantage you mention mean I'm not sure I
like it that much, though...

> Any comments? The main reason I like these methods is that they are
> both more explicit than the PEP, and don't require the addition of
> any more special functions. However I can see the disadantages as
> well!

Well, thanks for your comments, but I'm not sure I want to incorporate
your ideas... I'll add the "onexit" idea as an alternative.

Cheers,
mwh

-- 
  Gullible editorial staff continues to post links to any and all
  articles that vaguely criticize Linux in any way.
         -- Reason #4 for quitting slashdot today, from
            http://www.cs.washington.edu/homes/klee/misc/slashdot.html