-1

I'm taking an online Python course. One of the exercises contains:

[print(x, 'has type', type(eval(x))) for x in ['np_vals', 'np_vals_log10', 'df', 'df_log10']]

To me, this long statement is less readable than a standard loop, e.g.,

for x in ['np_vals', 'np_vals_log10', 'df', 'df_log10'] :
    print(x, 'has type', type(eval(x)))

Is there some kind of recommended practice against this kind of thing?

I write long lines in bash to take advantage of piping and substitution, and so that I can cobble and edit the whole using the vi input mode -- but I do so knowing that it would be written differently for readability in a script.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
user36800
  • 2,019
  • 2
  • 19
  • 34
  • 4
    *Never* write a list comprehension just for its side effects - if you don't use the list you created, you're doing it wrong. Any kind of course that contains code as horrible as that without a big, **fat**, "THIS CODE IS BAD" disclaimer should be dropped immediately. – Aran-Fey Sep 21 '19 at 05:11
  • The Zen of Python says: "Readability counts.". If you consider it more readable you can also consider it better. – Klaus D. Sep 21 '19 at 05:16
  • @Aran-Fey: Well, I haven't gotten to list comprehension yet, and don't want to stray too far from the course (I know what happens when I get too scattered rather than reinforcing a bit at a time). But I find this course valuable for its eventual intro to time series. And it's part of the a sea of courses provided by a rather big provider, one which has many other good courses. So I don't want to abandon it. – user36800 Sep 21 '19 at 05:18
  • Apart from list comprehension, though, I found [this advice](http://www.python.org/dev/peps/pep-0008/#maximum-line-length) to not exceed 79 characters per *physical* line, but nothing about length of a statement. Though I guess if the author had broken the statement into two physical lines, it would be better. – user36800 Sep 21 '19 at 05:20
  • @Klaus D: It's not just the length of the line. It's the fact that a code pattern was used which enabled a long statement but which didn't add any value. Why even use that "backward" loop pattern in this case? Because one can? To showcase a Python feature? I wouldn't consider that the best way to showcase a feature. It is puzzling. – user36800 Sep 21 '19 at 05:21
  • In Bash, you should have a newline after each pipe anyway — long lines are just as bad in Bash as in Python. – Jonathan Leffler Sep 21 '19 at 05:25
  • Yes, that's why I would format it properly in a script. On the command line, however, I want to access the whole statement using vi style input mode, so I often work on a franken-line. – user36800 Sep 21 '19 at 05:27

1 Answers1

2

Python has several widely used style guides that provide suggestions how to handle long lines in general and styling specific statements such as the list comprehension in your example.

Pep8 is baseline for most as it is based on Python's creator's insights.

There are other general purpose style guides with more suggestions, i.e. Google's and the Hitchicker's guide to Python. Searching for "long line" or the specific programming construct you are looking to style should yield relevant suggestions.

Most of these style guides also have formatters that can enforce them automatically and / or by demand, usually with some level of customization. You can find a nice overview of such formatters here.

Moshe Jonathan Gordon Radian
  • 1,272
  • 1
  • 12
  • 20
  • In a comment under my original post, I reference the line length from Pep8, but it doesn't seem to justify the use of list comprehension here, and the result long line. The hitchhiker's guide says "some compound statements such as list comprehensions are allowed and appreciated for their brevity", but in this case, the alternative of a conventional loop is simpler and briefer. So there doesn't seem to be a rationale for using list comprehension here, and its longer line. – user36800 Sep 21 '19 at 05:51
  • Style guides are guidelines, not steadfast rules. In my previous company we increased our line limit since 89 stopped making sense for modern resolutions / screens (one reason for short lines is meant to ensure they don't require scrolling). As for comprehensions - and as mentioned in the first comment to your post - the example you've given is frankly an abuse of the pattern, which is why it's no better than a loop. There are use cases where it is worthwhile (i.e. https://towardsdatascience.com/how-list-comprehensions-can-help-your-code-look-better-and-run-smoother-3cf8f87172ae). – Moshe Jonathan Gordon Radian Sep 21 '19 at 08:13
  • Agreed, I'm not thinking of guidelines as rules, but considerations. As I mentioned, the Pep8 guidelines only advocate short physcial lines, and don't say anything about entire statement length. One of the reasons is that, even today, you often don't want to take up the entire widescreen with a single code editor pane, and furthermore, you might be looking at multiple windows of code, often side-by-side. I try to keep physical lines of text no longer than 70 columns simply because I always get burned when I don't. – user36800 Sep 21 '19 at 22:47
  • About the comment on list comprehension abuse, it was specifically about using the side effects rather than the resulting list. I see that as tangential because I can overlook that if there was some pro to it. But there seems to be nothing to be gained in this case other than bad readability. The page you cited points out how list comprehension can be unreadable, and in this case, readability can be saved by breaking the statement into 2 physical lines. But that takes more syntax than the alternative conventional loop, and again, there seems to be no benefit to this choice in code pattern. – user36800 Sep 21 '19 at 22:47
  • That's exactly the point - we say a pattern is abused not because of some politenes rules, but exactly because choosing it in certain cases (i.e. list comprehensions only for their side effects) is not adding clarity, exactly because it is not the right usage for the pattern. Technically speaking, many python statements can be done in one line by simply adding ; as separators - it's valid syntax, but obviously it misses the mark on how to properly reduce lines. Optimizing only for that can justify many bad stylistic decisions, which is why style guides discuss more than just file length ;) – Moshe Jonathan Gordon Radian Sep 22 '19 at 06:04
  • Maybe I'm misunderstanding. I can live with coding for side effects and throwing away the result. As long is there is a pro that outweighs the cost in readability. Perhaps we're saying the same thing in different words, but the focus on side effects makes me think that we might not be. – user36800 Sep 23 '19 at 16:20
  • If you understand there is no pro to using comprehensions in your example above - we are on the same page. I focus on the side effects because it's a bigger "con" than readability in this case, not the fact that list comprehensions aren't always readable, which isn't always the case. – Moshe Jonathan Gordon Radian Sep 24 '19 at 07:08
  • Ah. Thanks for clarifying. – user36800 Sep 25 '19 at 00:20