List Comprehension Syntax

[Dave Brueck]

Eric S. Johansson wrote:
> Ville Vainio wrote:
>> It's just a matter of getting used to it. Admittedly LC's are
>> sometimes confusing for newbies, but they are an example of such a
>> feature where the tradeoff between newbie and non-newbie friendliness
>> has really paid off.
> 
> as someone approaching 25 years experience with programming languages 
> and their implications, I find list comprehension's incomprehensible. 
> Personally I think my learning is inhibited by the documentation which 
> seems driven by the syntax of list comprehensions rather than the 
> execution model and how to recognize when it's appropriate to apply that 
> model.

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)

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