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

[Peter Hansen]

Moosebumps wrote:

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

result = [x for x in range(10)
if x % 2 == 0
if x % 3 == 0
]

result = [x * y
for x in range(10) if x % 2 == 0
for y in range(10) if y % 3 == 0
]

Probably something like that?

-Peter

[Ville Vainio]

Moosebumps wrote:

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

Peter indents:
---------------
result = [x for x in range(10)
if x % 2 == 0
if x % 3 == 0
]

result = [x * y
for x in range(10) if x % 2 == 0
for y in range(10) if y % 3 == 0
]

-----------------

Nope, the only correct way is
result = [x for x in range(10)
if x % 2 == 0
if x % 3 == 0
]

result = [x * y
for x in range(10) if x % 2 == 0
for y in range(10) if y % 3 == 0
]

Because that's the way python-mode.el does it in emacs :-).

--
Ville Vainio http://tinyurl.com/2prnb

[James Moughan]

Andrea Griffini <ag****@tin.i t> wrote in message news:<f5******* *************** **********@4ax. com>...

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

Yup, scoping rules are usually the one confusing part of Python. I was
especially surprised by the result of:

l = [lambda y: x*y for x in range(10)]

which doesn't do remotely what you'd expect. Especially if you
learned about list comprehensions in Haskell, with no variable
assignments... :-)

[Matthew Scott]

Ville Vainio wrote:

Nope, the only correct way is
result = [x for x in range(10)
if x % 2 == 0
if x % 3 == 0
]

result = [x * y
for x in range(10) if x % 2 == 0
for y in range(10) if y % 3 == 0
]

Because that's the way python-mode.el does it in emacs :-).

Unless, of course, you leave the opening bracket as the last character
on the line, in which case python-mode will prefer you to do this:

result = [
x for x in range(10)
if x % 2 == 0
if x % 3 == 0
]

result = [
x * y
for x in range(10) if x % 2 == 0
for y in range(10) if y % 3 == 0
]

:)

[Peter Hansen]

Ville Vainio wrote:

Nope, the only correct way is

result = [x for x in range(10)
if x % 2 == 0
if x % 3 == 0
]

result = [x * y
for x in range(10) if x % 2 == 0
for y in range(10) if y % 3 == 0
]

Because that's the way python-mode.el does it in emacs :-).

Unfortunately, python-mode.el is wrong, since it results
in code that is harder to maintain (at least with another
editor).

Indentation that has to line up with random items on
the previous line, as opposed to the standard four spaces,
is clearly wrong.

But if you let emacs define the limits of your world, then
it's probably okay to do it that way. ;-)

[François Pinard]

[Peter Hansen]

Unfortunately, python-mode.el is wrong, since it results in code that
is harder to maintain (at least with another editor).
I'm not arguing here if `python-mode.el' is right or wrong.

However, for me at least, the greatest virtue of Python is that one can
write it legibly, and maintainability mainly results from legibility.

Being easier or harder to maintain with this or that editor is rather
irrelevant, if legibility is at stake. A lot of people are using lesser
editors anyway, and do all their alignment "by hand".
But if you let emacs define the limits of your world, then it's
probably okay to do it that way. ;-)

I do see the smiley. Yet, if people use an editor which is more helpful
on the side of legibility, it's not limitative, but plain good for them!

--
François Pinard http://www.iro.umontreal.ca/~pinard

[Peter Hansen]

François Pinard wrote:

... for me at least, the greatest virtue of Python is that one can
write it legibly, and maintainability mainly results from legibility.
I don't find the legibility of the carefully aligned version of
that code to be higher than the simpler "indent the standard amount"
version of the code. Sometimes consistency is not foolish.

As for maintainability , the problem is not that other people
use an editor which makes it harder to produce the same level
of legibility (since I find the legibility the same or worse
with the "artistic" alignment). The problem is that other people
who use another editor (and it should be very clear that there
are such people and will always be) will find it much harder to
maintain alignment which, without editor support, requires
careful manual alignment.
Being easier or harder to maintain with this or that editor is rather
irrelevant, if legibility is at stake. A lot of people are using lesser
editors anyway, and do all their alignment "by hand".

If they do the alignment that way, making things carefully line
up with the parentheses, and manually, they are definitely wasting
their time, IMHO, because there is NO increase in legibility. I
used to do that... same as how I used to waste time lining up the
equals signs in initialization sections of my code. (Now the
only place I do such things is in sections where series of related
constants are assigned, since only there does it really produce
increased readability).

In a lot of ways, this is probably the same argument as that against
using TABs. People who like TABs most often seem to like them
because they feel TABs make it easier to tune things to their own
particular (more aesthetically pleasing) indentation standards.

In fact, since they are gaining arguably nothing (for example,
there are arguments that could be made about four spaces being
the optimal size, if we wanted to go there), but are making
maintenance harder for others, it's a net negative in the greater
scheme of things, though perhaps easier on themselves at
least in the short term.

(Wow... a simultaneous segue into both the tab war and the editor
wars! I think I'd better leave now...)

-Peter

[Ville Vainio]

>>>>> "Peter" == Peter Hansen <pe***@engcorp. com> writes:

Peter> But if you let emacs define the limits of your world, then
Peter> it's probably okay to do it that way. ;-)

It's just the path of least resistance - any other indentation
requires manual work, and won't reindent properly when pressing <tab>
on the line.

Anyway, the point is mostly moot because

blah = [
i + 1
for i in range(10)
if i != 3
]

indents the way you want it to, and that's the way I usually do it
anyway. I just M-x indent-region'ed your code snippet :).

Perhaps this is something that could be fixed in python-mode.el? I
mean making the indentation on the next line be previous_line + 4 in
bracket-opening situations... Or is the current behaviour better in
some generally agreed way?

--
Ville Vainio http://tinyurl.com/2prnb

[François Pinard]

[Peter Hansen]

François Pinard wrote:

... for me at least, the greatest virtue of Python is that one can
write it legibly, and maintainability mainly results from legibility.

I don't find the legibility of the carefully aligned version of
that code to be higher than the simpler "indent the standard amount"
version of the code.
That's the important point. Write for legibility! :-)
[...] same as how I used to waste time lining up the equals signs in
initialization sections of my code.
Yes, this is often abused, with not much gain. Agreed!
(Wow... a simultaneous segue into both the tab war and the editor
wars! I think I'd better leave now...)

We'll surely meet somewhere else, anyway! :-)

--
François Pinard http://www.iro.umontreal.ca/~pinard

[Isaac To]

>>>>> "Peter" == Peter Hansen <pe***@engcorp. com> writes:

Peter> If they do the alignment that way, making things carefully
Peter> line up with the parentheses, and manually, they are
Peter> definitely wasting their time, IMHO, because there is NO
Peter> increase in legibility.

Except that if you write things like

a=[[[1, 2],
[3, 4],
[5, 6]],
[[7, 8],
[5, 6]],
[9]]

as

a=[[[1, 2],
[3, 4],
[5, 6]],
[[7, 8],
[5, 6]],
[9]]

and say there is no lose of legibility, then I'll seriously question
your taste.

BTW, for somebody with python-mode installed and is using Emacs, it is
actually *harder* and a *bigger* waste of time to write the code as
you proposed, because by default whenever you press enter the cursor
is already at exactly the location in the former style, and you got to
count spaces in order to go to the place you proposed.

Regards,
Isaac.