Andrew Dalke wrote: >>def foo(): >> with locking(someMutex) >> with opening(readFilename) as input >> with opening(writeFilename) as output >> ... > > > Nothing in Python ends at the end of the current block. > They only end with the scope exits. The order of deletion > is not defined, and you would change that as well.
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. 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__. But yes, it creates a precedent by creating a statement affecting the end of the current indentation block. But that's what this PEP is all about... > Your approach wouldn't allow the following No, I said making the ':' *optional*. I totally agree supporting ':' is useful. > If the number of blocks is a problem it wouldn't be that > hard to do > > with multi( locking(someMutex), > opening(readFilename), > opening(writeFilename) ) as _, input, output: > ... True. But does it look as good? Particularly the _ part? Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list