Re: 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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: For review: PEP 343: Anonymous Block Redux and GeneratorEnhancements

[Paul Rubin]

"Delaney, Timothy C (Timothy)" <[EMAIL PROTECTED]> writes:
> Be sure to read the referenced PEPs (and the ones referenced from them)
> - they contain a lot of history. Also read PEP 346 for a competing PEP
> to PEPs 340 and 343 that gradually converged to PEP 343 - most
> importantly, it contains the rejected options (that seem to have been
> lost from PEPs 340 and 343).

There was an interesting proposal (later rejected) from Raymond
Hettinger a while back, that allowed passing arguments into a
suspended generator, where they could be seen by the yield statement.
I don't remember specifics and it doesn't seem to be in any of those PEP's.

Anyone remember more?  I wonder whether 343 could somehow resurrect
the good parts of that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: For review: PEP 343: Anonymous Block Redux and GeneratorEnhancements

[Mike Meyer]

Paul Rubin  writes:

> "Delaney, Timothy C (Timothy)" <[EMAIL PROTECTED]> writes:
>> Be sure to read the referenced PEPs (and the ones referenced from them)
>> - they contain a lot of history. Also read PEP 346 for a competing PEP
>> to PEPs 340 and 343 that gradually converged to PEP 343 - most
>> importantly, it contains the rejected options (that seem to have been
>> lost from PEPs 340 and 343).
>
> There was an interesting proposal (later rejected) from Raymond
> Hettinger a while back, that allowed passing arguments into a
> suspended generator, where they could be seen by the yield statement.
> I don't remember specifics and it doesn't seem to be in any of those PEP's.
>
> Anyone remember more?  I wonder whether 343 could somehow resurrect
> the good parts of that.

It sounds like you're remembering PEP 342. 343 references that, but
doesn't include much of it.

  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: For review: PEP 343: Anonymous Block Redux and GeneratorEnhancements

[Delaney, Timothy C (Timothy)]

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.

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?

The syntax:

with EXPR1 as VAR1, EXPR2 as VAR2:
...

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.

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.

Be sure to read the referenced PEPs (and the ones referenced from them)
- they contain a lot of history. Also read PEP 346 for a competing PEP
to PEPs 340 and 343 that gradually converged to PEP 343 - most
importantly, it contains the rejected options (that seem to have been
lost from PEPs 340 and 343).

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list