List Comprehension Syntax
Eric S. Johansson
esj at harvee.org
Sat Jul 10 16:42:04 CEST 2004
Ville Vainio wrote:
> 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 c.l.py (by Alex Martelli and others) changed
> that, for which I'm grateful and feel honor-bound to continue the
> pseudo-oral tradition :-).
I understand, having been the creator of more than a couple oral
> 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.
maybe that's the problem. I've never seen anyplace where it's easier to
use map and filter.
> 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
well, I do manipulate a few lists but more often, I manipulate
dictionaries. I tend to think more in terms of sets, bags and queues.
if you want to take on a bigger (open source) project, I have one you
can work on. ;-)
> 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.
I will show you what I create the easiest which I can guarantee you will
be a iterative solution. then maybe we can work through the process of
converting it to a list comprehension.
> 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
I've tried reading a few sources. and I'm not trying to throw bricks
because I do know how hard it is to write user understandable
documentation especially if you have been totally immersed in a project
for a while.
> 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.
but even good tools can be used for the purposes of evil... ;-)
More information about the Python-list