科学Python代码的可读性（行连续体、变量名、导入）

Python的风格最佳实践是否适用于科学编码

我发现很难让科学Python代码保持可读性

例如，建议为变量使用有意义的名称，并通过避免

import*

来保持名称空间的有序性。因此，例如：

    import numpy as np
    normbar = np.random.normal(mean, std, np.shape(foo))

但是这些建议可能会导致一些难以阅读的代码，特别是考虑到79个字符的线宽。例如，我刚刚编写了以下操作：

net["weights"][ix1][ix2] += lrate * (CD / nCases - opts["weightcost_pretrain"].dot(net["weights"][ix1][ix2]))

我可以跨行跨越表达式：

net["weights"][ix1][ix2] += lrate * (CD / nCases - 
     opts["weightcost_pretrain"].dot(net["weights"][ix1][ix2]))

但这似乎并没有好多少，我也不确定第二行缩进的深度。如果将一行缩进嵌套循环中，并且一行中只有50个字符，那么这些类型的行连续体将变得更加棘手

我应该接受scientific Python看起来很笨重，还是有办法避免上面例子中的行

一些可能的方法是：

• 使用较短的变量名
• 使用较短的字典键名
• 直接导入numpy函数并为其指定短名称
• 定义算术运算组合的辅助函数
• 将操作分解为更小的部分，并在每条线上放置一个

我希望大家能就其中的哪一项提出明智的意见，避免哪一项，并提出其他补救措施的建议

• 定义算术运算组合的辅助函数
• 将操作分解为更小的部分，并在每条线上放置一个

这些都是与PEP 8背后的意图一致的好主意，并且总体上与Python风格一致。事实上，每当有人建议修改PEP 8以提供更多关于长线的信息时，一半的回答通常是“如果你超过了线的限制，那么你可能在一个表达式中做得太多了”

而且，更一般地说，分解代码并为合理的操作指定合理的名称始终是一个好主意

当然，在不知道所有这些东西到底代表什么的情况下，我只能猜测如何将它们分开，但我认为这样的东西会非常可读和有意义：

cost = opts["weightcost_pretrain"].dot(net["weights"][ix1][ix2])
weight = lrate * (CD / nCases - cost)
net["weights"][ix1][ix2] += weight

---

我认为风格指南总是适用的——我每天使用Python进行科学研究，发现如果我将长行拆分为逻辑组件和合理的变量名，或者使用函数，我可以更轻松地阅读代码，几个月后再回来阅读

我会做更像这样的事情：

weights = net["weights"][ix1][ix2]
opts_arr = opts["weightcost_pretrain"]
weights += lrate * (CD / nCases - opts_arr.dot(weights))

---

说Python“简洁”的另一种方式是Python语法密集，我发现阅读和理解一长行Python比理解一长行Java更难（特别是当使用隐藏低级逻辑的第三方库中的高级函数时，如NumPy）现在，当PPEP 8提高了可读性时，它允许行最多99个字符。你的最后两个方法与PEP 8和Python风格一般非常一致。@ RIPPI：“限制所有行最多79个字符……为流动的长块…72个字符。”“一些球队强烈喜欢更长的队伍长度。对于专门或主要由能够就此问题达成一致意见的团队维护的代码，可以将标称行长度从80增加到100（有效地将最大长度增加到99个字符），前提是注释和文档字符串仍然包装为72个字符。“@roippi：换句话说，它允许99个字符行，但仅限于它允许制表符，允许UTF-8和ASCII以外的编码，等等@abarnert我看到他们用+1偷偷地把那一行加进去。我喜欢Python语法密集的观点。当然，Java或Smalltalk的拥护者会告诉您，这就是为什么运算符重载是一个坏主意，但实际上，这意味着过长的行的成本更高，并且只要避免过长的行，Python就非常可读。（就像数学记数法与英语描述相比，写一个方程式是可能的，只要它不能被处理，但它很容易避免，而且只要你这么做，数学就更容易阅读。）