For review: PEP 343: Anonymous Block Redux and Generator Enhancements

[Andrew Dalke]

Nicolas Fleury wrote:
> There's no change in order of deletion, it's just about defining the 
> order of calls to __exit__, and they are exactly the same.

BTW, my own understanding of this is proposal is still slight.
I realize a bit better that I'm not explaining myself correctly.

> As far as I 
> know, PEP343 has nothing to do with order of deletion, which is still 
> implementation-dependant.  It's not a constructor/destructor thing like 
> in C++ RAII, but __enter__/__exit__.

I'm mixing (because of my lack of full comprehension) RAII with
your proposal.

What I meant to say was in the PEP

     with locking(someMutex)
         with opening(readFilename) as input
             with opening(writeFilename) as output
                 ...

it's very well defined when the __exit__() methods are
called and in which order.  If it's


     with locking(someMutex)
     with opening(readFilename) as input
     with opening(writeFilename) as output

with the __exit__()s called at the end of the scope (as if it
were a __del__, which it isn't) then the implementation could
still get the __exit__ order correct, by being careful.  Though
there would be no way to catch an exception raised in an __exit__.
I think.
 
>> Your approach wouldn't allow the following
> 
> No, I said making the ':' *optional*.  I totally agree supporting ':' is 
> useful.

Ahh, I think I understand.  You want both

with abc:
  with cde:
    pass

and

with abc
with def

and to have the second form act somewhat like RAII in that
the __exit__() for that case is called when the scope ends.


Hmm.  My first thought is I don't like it because I'm a stodgy
old traditionalist and don't like the ambiguity of having to look
multiple tokens ahead to figure out which form is which.  

I can see that it would work.  Umm, though it's tricky.  Consider

with abc

with defg:
  with ghi
  with jkl:
    1/0



The implementation would need to track all the with/as forms
in a block so they can be __exit__()ed as appropriate.  In this
case ghi.__exit() is called after jkl.__exit__() and
before defg.__exit__

The PEP gives an easy-to-understand mapping from the proposed
change to how it could be implemented by hand in the existing
Python.  Can you do the same?

> True.  But does it look as good?  Particularly the _ part?

I have not idea if the problem you propose (multiple with/as
blocks) will even exist so I can't comment on which solution
looks good.  It may not be a problem in real code, so not needing
any solution.

				Andrew
				dalke at dalkescientific.com