List Comprehension Syntax

Ville Vainio ville at
Sat Jul 10 15:41:16 CEST 2004

>>>>> "Eric" == Eric S Johansson <esj at> writes:

    Eric> as someone approaching 25 years experience with programming
    Eric> languages and their implications, I find list
    Eric> comprehension's incomprehensible. Personally I think my
    Eric> learning is inhibited by the

I found LC's a bit odd too at first. Previous programming experience
probably doesn't matter too much with them, because they are quite

    Eric> documentation which seems driven by the syntax of list
    Eric> comprehensions rather than the execution model and how to
    Eric> recognize when it's appropriate to apply that model.

Probably. It's all too easy to dismiss if the documentation doesn't
sell it well (this is fixable, luckily). I kinda ignored LC's too, but
persistent ramblings on (by Alex Martelli and others) changed
that, for which I'm grateful and feel honor-bound to continue the
pseudo-oral tradition :-).

The main thing to realize about list comprehensions is that
they simply provide a more elegant way to do 'map' and 'filter' when a
function to be applied is not something trivial like str or
int. Having LC's handy urges one to go ahead with map/filter like
approaches to problems where implementing new functions (or calling
old ones via lambda) seems like an unnecessary hassle.

    Eric> I find multiple short lines actually easier to comprehend
    Eric> because it translates into a common mental model of mine.

It helps if your mental model involves manipulating lots of
lists. I've found that the list manipulation model works great for me,
allowing me to solve most problems quickly and (I think) elegantly. I
guess it depends a lot on what you are doing - my python use is mostly
just scripting these days (for reasons not in my control, of course

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

Good for you. Do it with map and filter (and in-scope funcs using
closures) and go LC only afterwards if that feels easier. I believe
people still feel more comfortable with LCs than nested scopes,
because the LC is "visually" more in the same scope. The part after
"and/or" seemed too mysterious to give the solution now, but it seems
you'll need to implement a function in addition to the LC to keep the
solution clean.

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

Do you feel it's the offical docs that are lacking, or have you tried
reading some Python books? I've probably been in the "enthusiast"
crowd that gets a kick from reading those "what's new" docs, PEPs and

    Eric> experience has been that any time you find yourself having
    Eric> to "thinking in the language", you are not really solving
    Eric> the right problem and are more likely using a collection of
    Eric> magic tricks to confound and amaze others and possibly
    Eric> insure job security.

    Eric> if you have models that can be implemented independent of
    Eric> the language and you can express a problem in terms that are
    Eric> natural to the problem, you invariably have a better
    Eric> solution for the people following you as well as the
    Eric> machine.

Luckily, the underlying model of LCs is very well understood (map &
filter), and solving things the list-processing way is a time-honed
practice. In the "amaze your friends" front, LCs are more in the "look
how elegant and concise this can be" genre, not in the "check this
out, all recursion and no variables, I bet you can't get it even after
staring it for 5 minutes" genre loved by some academics.

I think you'll find that you don't need to sacrifice any of your old
models or even aesthetic preferences to appreciate LCs. 

Ville Vainio

More information about the Python-list mailing list