Question

我将在这里使用argparse作为例子，但我认为它适用于很多事情。考虑：

parser = argparse.ArgumentParser(description="This is a description of how this program works.")
subparsers = parser.add_subparsers(title="subcommands")
parser_sub1 = subparsers.add_parser("sub1",
                                    description="subcommand 1 does something something something")
parser_sub1.add_argument("arg1",
                         help="Arg1 does somethign something something.")

等20条丑陋的线条。

add_argument，特别是add_parser行很长，很大程度上是因为help / description字符串。但我认为没有明显的方法可以干净地缩短它们。正如您所看到的，以通常方式在第二行缩进只会获得几个字符。将字符串拆分为多行会很快变得尴尬。

我在通过-m pep8运行一些代码时遇到了这个问题，它抱怨几乎每个add_argument行都是> 80个字符。根本问题似乎是直到开括号的行的部分本身太长以至于不适合后面的字符串，即使在参数之间存在间断和缩进。我可以通过以下几种方式来解决这个问题：

活得很长，忽略了pep8
缩进延续行并忽略pep8
使用非常短的变量名来保存字符（例如ps1 = parser.add_subparsers(whatever)
别名我可以保存更多内容（例如每个块psaa = parser_sub1.add_argument）
制作一堆字典文字，然后用**解压缩到函数调用中（但是我找到dict文字很难处理）
从一个不太笨拙的格式的外部文件中读取函数调用参数，可能是YAML，然后解压缩（但是你不能告诉代码在做什么而不必引用另一个文件）
......别的什么？

是否有一种已知的有效方法来处理冗长的函数参数，当自然写入时，它们会被80个字符约定所阻塞？

Answer 1

这是一个品味和意见的问题，但在这里，有两个！

很少有真正的代码坚持严格的80列建议。它值得避免笨拙的长线，但是狭隘地坚持一个源于打卡的约束是愚蠢的。 PEP8也解决了这个问题：

有些团队更喜欢更长的线路长度。维护代码完全或主要由可以就此达成一致的团队问题，可以将标称线长从80增加到100 字符（有效地将最大长度增加到99 字符）

对于这样的事情，制作一些你通过文字表达的数据结构，然后通过** args或with循环进入配置调用可能是最安静的。它使所有文本可读，内联和在一个地方，因此易于编辑。您应该能够在代码中间找到一个看起来模糊文档的blob。

Answer 2

x = ('string literal broken across two lines '
...  'but it works because the parens keeps them together.')
>>> x
'string literal broken across two lines but it works because the parens keeps them together.'

>>> print('If this was already in the parens of an argument list '
...       'you are already in a context where string literal '
...       'concatenation works.')
If this was already in the parens of an argument list you are already in a context where string literal concatenation works.

如何设置长函数调用的代码？

2 个答案: