List Comprehension Syntax

[Moosebumps]

> What I like about LCs is that they made sense to me before reading the
> documentation - they just came across as very expressive of what was
> happening. I use the simplest forms, i.e.
>
> [op(x) for x in y]
> [x for x in y if z]
> (as well as some slight variations)

That's true, I tend to use the simplest forms too -- but then that is not as
maintainable.

We all know that things don't always stay so simple.  There is always
something you need to add.  IMO with that in mind, it is easier to keep
everything consistent, then to try to "sneak in" the LC for the simpler
cases.  You would end up flipping back and forth too much when you need to
add a condition, or add an expression.

>
> quite a bit, but rarely do I use the more complex forms (e.g. multiple
> for's) because (1) the meaning doesn't jump right out as quickly (to me)
> and (2) the more complex they are, the more they seem like a fancy trick
> rather than the right thing to do.
>
> But most any time you're using map or filter or basically doing:
>
> L = []
> for item in L2:
>    L.append(op(item))
>
> the LC form is often more desirable because it screams "I'm taking a
> sequence and using it to create a list" - the intent of the code is very
> clear. And by extension, if you're using an LC to do something obtuse,
> you deserve a slap on the wrist (e.g. you write [f() for f in x] and
> throw away the resulting list).
>
> >> Now that genexps are coming around, you'll be facing even bigger
> >> payoffs. So just keep using them, even if they might not feel as
> >> maintanable at the moment. LC's (and genexps even to a bigger extent)
> >> are pretty much what defines the "pythonic" way of doing things for me
> >> these days.
> >
> > this is not meant to be picking on you in any way shape or form but my
> > experience has been that any time you find yourself having to "thinking
> > in the language", you are not really solving the right problem and are
> > more likely using a collection of magic tricks to confound and amaze
> > others and possibly insure job security.
>
> That's not what I understood by Ville's comment. I think he just meant
> that LC's (and genexps) are powerful tools in the Python toolbox, and
> useful enough that the OP should continue working to become familiar
> with them. They're not obscure magic tricks but "first class" features
> of the language.
>
> I've seen many comments on c.l.py to the effect of "LCs seem bad because
> they can abused", citing bizarre made-up examples with 4 loops and as
> many if statements. Those *are* magic tricks and should be avoided, but
> then again any feature can be abused.
>
> > if you have models that can be implemented independent of the language
> > and you can express a problem in terms that are natural to the problem,
> > you invariably have a better solution for the people following you as
> > well as the machine.
> >
> > generalize, don't pythonize.
>
> I'm not so sure. Why program to the lowest common language denominator?
> I don't suggest going to the extreme to use obscure language quirks just
> because you can, but it doesn't make sense to avoid using a feature at
> your disposal because it's unique to a language (or, in this case, a
> small set of languages).
>
> Half the reason you use one language over another is because of the
> toolset it gives you. In the case of list comprehensions, they are
> usually chosen for the very reason that they *do* allow you to express a
> problem in natural terms.
>
> -Dave