For review: PEP 343: Anonymous Block Redux and GeneratorEnhancements

[Nicolas Fleury]

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