List Comprehension Syntax

[Eric S. Johansson]

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

> 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
> such?

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

---eric