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 [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list