List Comprehension Syntax

[Peter Hansen]

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]

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 .

 

[James Moughan]

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]

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]

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

 

[=?iso-8859-1?Q?Fran=E7ois?= 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!

 

[Peter Hansen]

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

 

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[Peter Hansen]

François Pinard wrote:

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!

 

[Ville Vainio]

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?

 

[Isaac To]

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.

 

[Peter Hansen]

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.

Not sure what you mean here. The indentation approach I'm
referring to (i.e. the "standard" way, as opposed to what I
was calling the "artistic" way) is just to hit tab in precisely
the same way you would if you were indenting an "if" block.

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 .

Not sure which code-snippet you refer to, but the ones that I
typed were indented the same way, except perhaps that I put
the first expression the same line as the opening bracket.

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?

Nope, definitely not in a generally agreed way. I don't think anyone
thinks this issue is on par with the tab war though, so until that
particular war is won, we're best off leaving this issue to personal
preference. (That is to say, "forever".

-Peter

 

[Peter Hansen]

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.

Ugh. But nobody should write something like the first one, either.
(And I won't say how it should be written without a real example,
since otherwise we can each contrive all kinds of interesting and
meaningless ways to format something that nobody would actually
write.)

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.

Not sure which one you think I proposed, but you definitely don't
have to count any spaces in order to do what I suggested. You
hit ENTER and TAB (once), exactly as you would with any other
block. Note that this (hitting TAB once) of course relies on
an editor which auto-indents to the same level as the preceding
line of code by default. Any editor which does not do at least
this, these days, is broken. But counting spaces would be silly.
What editor are you using that would force you to do that? vi
without a Python configuration?

-Peter

 

[Larry Bates]

I don't agree that the second is "less maintainable",
but do find it "wordy" for little reason. Try:

result=[x.replace('blah','moof') for x in L if x.startswith('blah')]

or if you prefer short lines:

result=[x.replace('blah','moof') \
for x in L \
if x.startswith('blah')]

Note: BAD idea to call variable 'list' as it kills the
list function for remainder of Python session (I changed
to L). For same reason never call variable 'dict', 'str',
etc. Using startswith also takes care of not having to
get the slice correct (which is easier to maintain should
you change 'blah' to something else, you don't have to
mess with the slice).

Larry Bates
Syscon, Inc.

 

[Ville Vainio]

Peter> Not sure what you mean here. The indentation approach I'm
Peter> referring to (i.e. the "standard" way, as opposed to what I
Peter> was calling the "artistic" way) is just to hit tab in
Peter> precisely the same way you would if you were indenting an
Peter> "if" block.

In emacs, tab is 'indent-line', which gives the line "correct"
indentation. Occasionally one needs to dedent a line manually to close
a block. Pressing <enter> puts the cursor in the right place
immediately (indenting on ':', dedenting on 'return').

if 1:
hui();

If I press tab on line with hui(), the result is

if 1:
hui();

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

Peter> Not sure which code-snippet you refer to, but the ones that
Peter> I typed were indented the same way, except perhaps that I
Peter> put the first expression the same line as the opening
Peter> bracket.

Yes, and that made the difference.

 

[Aahz]

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]

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

Wouldn't use either.

 

[David Eppstein]

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]

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

Wouldn't use either.

I would probably use instead something like

[x for x in range(0,10,6)] [0, 6]
[x*y for x in range(0,10,2) for y in range(0,10,3)]

[0, 0, 0, 0, 0, 6, 12, 18, 0, 12, 24, 36, 0, 18, 36, 54, 0, 24, 48, 72]

I think two for or if clauses in a comprehension is the most I'd want to
use on a regular basis. I certainly wouldn't use two ifs in a row as in
your first example, I'd use and instead.