Delaney, Timothy C (Timothy) wrote: > Nicolas Fleury wrote: >>def getFirstLine(filename): >> with opening(filename) as file >> return file.readline() > > Your tastes definitely disagree with the majority of Python programmers > then, including Guido. Scoping is defined in Python by indentation.
I'm very happy to met someone who can speak for the majority of Python programmers, I should have chat with you in the first place;) But you're right, that would make a precedent in Python, and that is probably what makes my proposal so bad. Someone could argue that this should be allowed too: with locking(lock) if condition with opening(filename) as file for line in file ... And that's horrible IMO (and a no-no to me). About the majority of Python programmers, a lot of newcomers come from languages where you don't have to make a new block for an acquire/release pattern. Also, the following syntax: decorate staticmethod: def foo(): ... have been rejected for decorators. All this to say that over-indentation can be an issue. > If you want the above sort of thing, you're going to have to write a new > PEP, and I'd be very surprised to see it accepted. But there's nothing > stopping you from doing so. > > >>def getFirstLine(filename): >> with opening(filename) as file: >> return file.readline() > > This is beautiful and explicit. What else could you want? Did you deliberately keep that example instead of the other one in the message? with locking(lock): if condition: with opening(filename) as file: for line in file: ... It is definately explicit, but beautiful? Add to that the indentation of the class, of the method, a few more with-statements and you end up with something that makes it difficult to respect PEP008 (4 spaces indentation and lines < than 80). Compare that with the += like operators. It is not beautiful, but very usable. The same can be said for @decorators. > The syntax: > > with EXPR1 as VAR1, EXPR2 as VAR2: > ... That syntax doesn't help in the previous example. > was discussed on python-dev. It wasn't explicitly rejected, but the > feeling seemed to be that it was an unnecessary complication as far as > PEP 343 is concerned. There's nothing stopping another PEP proposing > this as an extension to PEP 343, and there's nothing stopping that being > in Python 2.5 if it's accepted. I totally agree. I don't want to change PEP343, but keeping the door open for a no-indentation syntax is a good idea. > PEP 343 was originally PEP 340 (and several other things) and was quite > complicated at one point (it originally contained PEP 342 as well). The > PEP in its current state represents 2 months of discussion, complication > and (finally) simplification. Its semantics are clear and unambiguous. > And (as Guido states) it will obsolete 4(?) other PEPs. I know, and I followed these discussions even in vacation. I'm very happy with the result. I'm just pointing that it will result in over-indented code. In some situations indentation is necessary anyway, so the PEP syntax is fine. Will I write a PEP for that? Maybe. I think the first step is to just use with-statements in real-life code and see how it comes. But I will not be surprised if it is added someday. Regards, Nicolas -- http://mail.python.org/mailman/listinfo/python-list