List Comprehension Syntax

[Moosebumps]

Does anyone here find the list comprehension syntax awkward?

I like it because it is an expression rather than a series of statements,
but it is a little harder to maintain it seems.

e.g. you could do:

result = []
for element in list:
if element[0:4] == 'blah':
result.append( element.replace ( 'blah', 'moof' ) )

or just:

result = [ element.replace ( 'blah', 'moof' ) for element in list if
element[0:4] == 'blah' ]

The second looks cleaner in some cases, but it is less maintainable. It
tends to promote long lines. It all seems to run together and such. And
often you would need to add another condition or modify it, it seems better
to use the first way even though it has the ugly extra init (and which would
cause more allocs than the list comprehension? because it wouldn't know the
size off the bat?)

I am in favor of short lines like I think Guido said in the style guide. I
like each line to be so simple as to not require any thinking reading it,
e.g.

I prefer:

x = c( d, e )
y = f( g, h )
z = b( x, y )
w = a( z )

to stuff like this:

w = a( b( c( d, e ), f( g, h ) ) )

It is more maintainable, when you need to make a change, just insert a line,
rather than having to decode an expression.

Along the same lines, it seems more maintainable to split things up.

You could do:

result = [
element.replace ( 'blah', 'moof' )
for element in list
if element[0:4] == 'blah' ]

I guess, but that seems awkward to me. Looks too much like a for loop and
an if, and then the value is at the top, which reads funny to me.
(Strangely putting it on one line doesn't read as funny, but it is less
readable.) Maybe I just have to get used to it. Which do you prefer?
Comments?

MB

[Mitja]

Moosebumps <cr**@crap.crap >
(news:j9******* **********@news svr25.news.prod igy.com) wrote:

You could do:

result = [
element.replace ( 'blah', 'moof' )
for element in list
if element[0:4] == 'blah' ]

I guess, but that seems awkward to me. Looks too much
like a for loop and an if, and then the value is at the
top, which reads funny to me. (Strangely putting it on
one line doesn't read as funny, but it is less readable.)
Maybe I just have to get used to it. Which do you
prefer? Comments?

I usually do
result = [
element.replace ( 'blah', 'moof' )
for element in list
if element[0:4] == 'blah'
]
It seems clean and logical enough to me - like e.g. defining big dicts.

[Andrea Griffini]

On 10 Jul 2004 16:41:16 +0300, Ville Vainio <vi***@spammers .com>
wrote:

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

I'm quite new to python, and I found LC quite simple to understand
and powerful. The only "suprising" part for me was that the looping
variable is not local... I slipped on that a couple of times.
A list comphrension is very "local" in my mind ... I would say that
[x*x for x in xrange(10)] is just a list of perfect squares, but
instead it's not... it's that AND the assignment to x of the value 9.

Andrea

[Moosebumps]

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)
That's true, I tend to use the simplest forms too -- but then that is not as
maintainable.

We all know that things don't always stay so simple. There is always
something you need to add. IMO with that in mind, it is easier to keep
everything consistent, then to try to "sneak in" the LC for the simpler
cases. You would end up flipping back and forth too much when you need to
add a condition, or add an expression.

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(ite m))

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

[Moosebumps]

"Ville Vainio" <vi***@spammers .com> wrote in message
news:du******** *****@mozart.cc .tut.fi...

>> "Moosebumps " == Moosebumps <cr**@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.

Yes, I agree completely! Note that I have no problem with the idea of LC, I
love the idea. I am math person, I am very used to the set syntax:

S = { A(x) | Vx in 2^T }

etc., where V is the "for all", 2^ is powerset, whatever.

I am just wondering about the syntax, that's all. Once you try to come up
with anything a little more complicated than the basic forms, they get to be
too unreadable and unformattable.

I agree it is far superior to use an expression when that is all you need,
and to only use statements when you need them!

MB

[Moosebumps]

I usually do
result = [
element.replace ( 'blah', 'moof' )
for element in list
if element[0:4] == 'blah'
]
It seems clean and logical enough to me - like e.g. defining big dicts.

But what if you have multiple for and if's? Seems like you would want to
indent them then.

I think I might just get used to the multiline syntax since LCs are very
useful... it just seems awkward for some reason.

result = [ x for x in blah if f(x) ]

seems more elegant than:

result = [
x
for x in blah
if f(x) ]

but I like to keep things consistent and have maintainability , so then the
second one wins. i.e. the second one "scales better" to more complicated
expressions!

MB

[Dave Brueck]

Moosebumps wrote:

What I like about LCs is that they made sense to me before reading the
documentati on - 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)

That's true, I tend to use the simplest forms too -- but then that is not as
maintainable.

We all know that things don't always stay so simple. There is always
something you need to add. IMO with that in mind, it is easier to keep
everything consistent, then to try to "sneak in" the LC for the simpler
cases. You would end up flipping back and forth too much when you need to
add a condition, or add an expression.

I can see the potential for a maintenance problem, but I haven't seen it
actually be a problem in practice.

Perhaps it's due in part to the fact that an LC normally wouldn't "grow"
more complex in isolation - the change would likely be tied to changes
in surrounding code as well - and so maybe the entire code block would
be refactored. Dunno... but compared to the number of times LCs are used
in code, the number of times they are later "unrolled" to the for-loop
form has been too low to worry about.

-Dave

[Mitja]

Moosebumps <cr**@crap.crap >
(news:8O******* ***********@new ssvr27.news.pro digy.com) wrote:

I usually do
result = [
element.replace ( 'blah', 'moof' )
for element in list
if element[0:4] == 'blah'
]
It seems clean and logical enough to me - like e.g.
defining big dicts.
But what if you have multiple for and if's? Seems like
you would want to indent them then.

Hm... I never used a complicated enough case :)
I still think I wouldn't indent them - it is clear enough how they corelate.
If anything, I'd do
foo = [
a*b
for a in range(10)
for b in range(10)
for c in ['foo','bar']
if 42==True
]

Can you have multiple ifs at all?

I think I might just get used to the multiline syntax
since LCs are very useful... it just seems awkward for
some reason.

result = [ x for x in blah if f(x) ]

seems more elegant than:

result = [
x
for x in blah
if f(x) ]

but I like to keep things consistent and have
maintainability , so then the second one wins. i.e. the
second one "scales better" to more complicated
expressions!

MB

[Reinhold Birkenfeld]

Mitja wrote:

Moosebumps <cr**@crap.crap >
(news:8O******* ***********@new ssvr27.news.pro digy.com) wrote:

I usually do
result = [
element.replace ( 'blah', 'moof' )
for element in list
if element[0:4] == 'blah'
]
It seems clean and logical enough to me - like e.g.
defining big dicts.

But what if you have multiple for and if's? Seems like
you would want to indent them then.

Hm... I never used a complicated enough case :)
I still think I wouldn't indent them - it is clear enough how they corelate.
If anything, I'd do
foo = [
a*b
for a in range(10)
for b in range(10)
for c in ['foo','bar']
if 42==True
]

Can you have multiple ifs at all?

No, but you can have if (...) and (...) or (...)

Reinhold

--
Wenn eine Linuxdistributi on so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems " ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix .linux.misc

[Moosebumps]

> > Can you have multiple ifs at all?

No, but you can have if (...) and (...) or (...)

Sure you can:

result = [x for x in range(10) if x % 2 == 0 if x % 3 == 0]
result [0, 6] result = [ x*y for x in range(10) if x%2 == 0 for y in range(10) if y % 3 == 0] result [0, 0, 0, 0, 0, 6, 12, 18, 0, 12, 24, 36, 0, 18, 36, 54, 0, 24, 48, 72]

It appears that you can have as many if's and for's as you like.

Just curious -- anyone care to tell me how they would format the above? (or
maybe you wouldn't write it all)

MB

[Reinhold Birkenfeld]

Moosebumps wrote:

> Can you have multiple ifs at all?

No, but you can have if (...) and (...) or (...)

Sure you can:

OK, thanks.

Reinhold

--
Wenn eine Linuxdistributi on so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems " ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix .linux.misc