Niko Matsakis <[EMAIL PROTECTED]> wrote:
> For what it's worth, I also favor the continue syntax Heiko compared
> his code against. Without it, you have to scroll to the end of the
> loop to know whether there is an else clause;
Only if the code doesn't fit on one screen, which it should.
Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Why isn't this good practice? It's not always sensible to refactor loop code
> to call methods (to make the loop body shorter), and it's a pretty general
> case that you only want to iterate over part of a generator, not over the
> whole content. Becau
Niko Matsakis <[EMAIL PROTECTED]> wrote:
>
> > I saw them. Your brain must be wired very differently
> > to mine, because I find loops with a continue in them
> > harder to follow than ones without -- exactly the
> > opposite of what you seem to prefer.
>
> Delurking for no particular reason:
>
> I saw them. Your brain must be wired very differently
> to mine, because I find loops with a continue in them
> harder to follow than ones without -- exactly the
> opposite of what you seem to prefer.
Delurking for no particular reason:
For what it's worth, I also favor the continue syntax Heik
Heiko Wundram wrote:
> Am Montag 22 Mai 2006 01:59 schrieb Josiah Carlson:
> > Not everyone finds list comprehensions easy to read.
>
> Why has Python added list-comprehensions, then? (or at least, why has Python
> added the 'if'-expression to list-comprehensions if they're hard to read?
LCs are
Heiko Wundram wrote:
> You can also do the same here (by using normal bracketing):
>
> for in (
>
>) if ( and
> and
> ):
So you want to be able to write the if in-line,
and then format it so that it's no lo
Heiko Wundram wrote:
> Yes, of course. Read my replies to Terry J. Reed, to Josiah Carlton, to
> Talin,
> to see why I chose to compare it to the 'continue' syntax.
I saw them. Your brain must be wired very differently
to mine, because I find loops with a continue in them
harder to follow than
Am Montag 22 Mai 2006 02:22 schrieb Greg Ewing:
> Heiko Wundram wrote:
> > for node in tree:
> > if not node.haschildren():
> > continue
> >
>
> Er, you do realise that can be written more straightforwardly as
>
>for node in tree:
> if node.haschild
Am Montag 22 Mai 2006 01:59 schrieb Josiah Carlson:
> > 1) It unifies the syntax for list comprehensions and for loops, which use
> > the
>
> No, it /partially unifies/ list comprehensions and for loops. To
> actually unify them, you would need to allow for arbitrarily nested fors
> and ifs...
>
>
Heiko Wundram wrote:
> 2) Just as I've replied to Terry J. Reed, if you find list comprehensions
> easy
> to read, you're also bound to be able to understand what "for in
> if :" does, at least AFAICT.
I tend to write non-trivial LCs on multiple lines, e.g.
l = [foo(x)
for x in stuf
Heiko Wundram wrote:
> for node in tree:
> if not node.haschildren():
> continue
>
Er, you do realise that can be written more straightforwardly as
for node in tree:
if node.haschildren():
--
Greg
_
Heiko Wundram <[EMAIL PROTECTED]> wrote:
>
> Am Sonntag 21 Mai 2006 22:11 schrieb Talin:
> > As a general guideline, I've noticed that proposals which are purely
> > syntactic sugar are unlikely to be accepted unless there is some
> > additional benefit other than just compression of source code.
Am Sonntag 21 Mai 2006 22:11 schrieb Talin:
> As a general guideline, I've noticed that proposals which are purely
> syntactic sugar are unlikely to be accepted unless there is some
> additional benefit other than just compression of source code.
I know about this, but generally, I find there's mo
Steven Bethard wrote:
> On 5/21/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
>
>>Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum:
>>
>>>This was proposed and rejected before.
>>
>>I haven't seen this proposed before (at least not in PEP form, or with a
>>working implementation against the cu
Am Sonntag 21 Mai 2006 18:08 schrieb Steven Bethard:
> While this has been proposed before, I'd like to thank you for putting
> together a full PEP and a working implementaiton. I think you should
> still submit the PEP, if for nothing else so that when the issue comes
> up again, we can point to
On 5/21/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum:
> > This was proposed and rejected before.
>
> I haven't seen this proposed before (at least not in PEP form, or with a
> working implementation against the current trunk, or just in some f
Am Sonntag 21 Mai 2006 17:38 schrieb Guido van Rossum:
> -1. The contraction just makes it easier to miss the logic.
I actually don't think so, because it's pretty synonymous to what 'if' means
for list comprehensions which use the same keywords (that's why I called
it "unification of ... syntax
-1. The contraction just makes it easier to miss the logic.
Also, it would be a parsing conflict for the new conditional
expressions (x if T else y).
This was proposed and rejected before.
--Guido
On 5/21/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> The following PEP tries to make
Hi all!
The following PEP tries to make the case for a slight unification of for
statement and list comprehension syntax.
Comments appreciated, including on the sample implementation.
===
PEP: xxx
Title: Unification of for-statement and list-comprehension syntax
Version: $Revision$
Last-Modifie
19 matches
Mail list logo
