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
