Too much code - slicing

[Seebs]

On 2010-09-23, Steven D'Aprano <steve-REMOVE-THIS at cybersource.com.au> wrote:
> On Thu, 23 Sep 2010 01:49:44 +0000, Seebs wrote:
>> But I do think it's unfair to dismiss it as purely a matter of baby duck
>> syndrome.  Consistency in ordering of corresponding idioms seems a
>> reasonable goal.

> I don't see anyone bitching about:

> for x in seq:
>     if x:
>         f(x)

> vs 

> [f(x) for x in seq if x]

In my case, that's because I only ran into that syntax about an hour and
a half ago.  I have the same basic objection to it.  If it were:

[for x in seq: if x: f(x)]

I'd find it substantially easier to understand.

I don't generally like constructs where important structural information
comes late in the construct.  In the trivial case, I don't suppose it makes
a huge difference, but think about the case where seq starts with a (
and x ends with one:

[f(x) for x in (1, 2, 3) if foo(x)]

As the expressions get complicated, that gets harder to see.  IMHO.

I dunno.  I like the "next if /^$/" idiom, but anything more complicated
for either the condition or the thing conditionalized and I tend to
prefer to jump back to an explicit if statement.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam at seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.