Python中的超长语句？

我正在上一门在线Python课程。其中一项练习包括：

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

对我来说，这个长语句不如标准循环可读，例如

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

有没有针对这类事情的推荐做法

---

我在bash中写长行以利用管道和替换，因此，我可以使用vi输入模式对整个脚本进行拼凑和编辑，但我知道，为了脚本的可读性，它的编写方式会有所不同。

Python有几个广泛使用的样式指南，它们提供了如何处理一般的长行以及如何设置特定语句的样式的建议，例如在脚本中的列表理解例如

是大多数人的基准，因为它基于Python的创建者的见解

还有更多建议的其他通用样式指南，即和。搜索长线或您正在寻找的特定编程构造样式应该会产生相关的建议

---

这些样式指南中的大多数还具有格式化程序，可以自动和/或按需执行它们，通常需要进行某种程度的自定义。您可以找到此类格式化程序的良好概述。

切勿仅为其副作用编写列表理解-如果不使用您创建的列表，则说明您做得不对。任何一种课程，如果没有一个大的、胖的、不好的免责声明，那么它包含的代码都是可怕的，应该立即删除。。如果你认为它更可读，你也可以认为它更好。“阿兰·费伊：嗯，我还没有得到列表理解，但不想偏离太远的课程，我知道什么会发生，当我太分散，而不是加强一点一次。但我发现这门课程对时间序列的最终介绍很有价值。这是一个相当大的供应商提供的一系列课程的一部分，这个供应商还有很多其他的好课程。所以我不想放弃它。尽管如此，除了列表理解，我发现每一物理行不超过79个字符，但和语句长度无关。虽然我想如果作者把这句话分成两行，那就更好了。@Klaus D:不仅仅是这行的长度。事实上，使用了一个代码模式，它启用了一个长语句，但没有增加任何值。在这种情况下，为什么还要使用反向循环模式？因为一个人可以？展示Python功能？我不认为这是展示一个特征的最好方式。这是令人费解的。在我的原始帖子下的一条评论中，我引用了Pep8中的行长，但它似乎不能证明在这里使用列表理解是合理的，并且结果是长行的。《搭便车者指南》说，一些复合语句，如列表理解，由于其简洁性是允许的，并受到赞赏，但在这种情况下，传统循环的替代方法更简单、更简洁。因此，这里似乎没有使用列表理解的理由，它的行数更长。样式指南是指导原则，而不是坚定的规则。在我以前的公司，我们提高了行限制，因为89不再适用于现代分辨率/屏幕。短行的一个原因是为了确保它们不需要滚动。至于理解，正如你在文章的第一条评论中提到的，你给出的例子坦率地说是对模式的滥用，这就是为什么它不比循环好多少。有些用例是值得的，也就是说，同意了，我不认为指导原则是规则，而是考虑因素。正如我所提到的，Pep8指南只提倡简短的物理语句，而没有提到任何关于整个语句长度的内容。其中一个原因是，即使在今天，您通常也不希望用一个代码编辑器窗格占据整个宽屏，而且，您可能会同时看到多个代码窗口。我尽量保持文本的实际行数不超过70列，因为我不这样做的时候总是会被烧掉。关于列表理解滥用的评论，特别是关于使用副作用，而不是结果列表。我认为这是无关紧要的，因为如果有人支持的话，我可以忽略这一点。但在这种情况下，除了糟糕的可读性之外，似乎什么也得不到。您引用的页面指出了列表理解是如何不可读的，在本例中，可以通过将语句分成两行来保存可读性。但这比其他常规循环需要更多的语法，而且，在代码模式中，这种选择似乎没有任何好处。这正是问题所在-我们说模式被滥用不是因为一些politenes规则，但正是因为在某些情况下选择它，即仅针对副作用列出理解并不能增加清晰度，正是因为它不是该模式的正确用法。从技术上讲，许多python语句可以通过简单的添加在一行中完成；作为分隔符-这是有效的语法，但是 很明显，它忽略了如何适当减少线条。仅为此进行优化可以证明许多糟糕的风格决策是合理的，这就是为什么风格指南讨论的不仅仅是文件长度；