List Comprehension Syntax

[Eric S. Johansson]

Ville Vainio wrote:

>>>>>>"Moosebumps" == Moosebumps  <crap at crap.crap> writes:
> 
> 
>     Moosebumps> Does anyone here find the list comprehension syntax awkward?
> 
> ...
> 
>     Moosebumps> I am in favor of short lines like I think Guido said
>     Moosebumps> in the style guide.  I like each line to be so simple
>     Moosebumps> as to not require any thinking reading it,
> 
> You need to think of the total complexity involved with having several
> lines. When you see a list comprehension, you know what to expect -
> transformation and/or filtering applied to a list. Therefore, you can
> easily read and write out the beast.
> 
> LC's also encourage the list transformation/filtering approach to
> problems, which I find absolutely splendid. Appending elements to a
> list manually is tedious, especially if the problem really is a
> stereotypical problem solved by a LC (and interestingly, most problems
> are ;-).
> 
>     Moosebumps> You could do:
> 
>     Moosebumps> result = [
>     Moosebumps> element.replace( 'blah', 'moof' )
>     Moosebumps> for element in list
>     Moosebumps> if element[0:4] == 'blah' ]
> 
>     Moosebumps> I guess, but that seems awkward to me.  Looks too much
>     Moosebumps> like a for loop and an if, and then the value is at
>     Moosebumps> the top, which reads funny to me.  (Strangely putting
>     Moosebumps> it on one line doesn't read as funny, but it is less
>     Moosebumps> readable.)  Maybe I just have to get used to it.
>     Moosebumps> Which do you prefer?
> 
> 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.

I find multiple short lines actually easier to comprehend because it 
translates into a common mental model of mine.  The current syntax for 
those comprehension's reminds me of APL which was a wonderful language 
if you thought in nothing but vectors.

I will admit this discussion has goaded me into trying to learn list 
comprehensions again as I am trying to solve a problem which is 
filtering a dictionary of data elements based on predicates selecting 
individual elements and/or predicates on the offset from the start of 
the previous predicate list.

By the way, similarly hampered-by-the-documentation are generators, 
iterators, and profiling time bases.  I'm having a lot of difficulty 
pulling out model abstractions, and as I said above, understanding where 
to apply them in problem spaces.

> 
> 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.

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.

---eric