Question

PEP 8未提及切片运算符。根据我的理解，与其他运算符不同，它不应该用空格包围

spam[3:5]   # OK
spam[3 : 5] # NOT OK

使用复杂表达式时，这是否成立，即哪一个被认为是更好的样式

     1. spam[ham(66)//3:44+eggs()]
     2. spam[ham(66) // 3: 44 + eggs()]
     3. spam[ham(66) // 3 : 44 + eggs()]
     4. something else?

Answer 1

正如您已经提到的，PEP8没有明确提到该格式的切片运算符，但spam[3:5]肯定更常见，恕我直言更具可读性。

如果要pep8 checker，:之前的空格会被标记

[me@home]$ pep8  <(echo "spam[3:44]")   # no warnings
[me@home]$ pep8  <(echo "spam[3 : 44]")  
/dev/fd/63:1:7: E203 whitespace before ':'

...但这仅仅是因为它假定:是定义文字字典的运算符，并且在运算符之前不会有空格。 spam[3: 44]因为这个原因而通过，但这似乎不对。

在那个数上，我坚持spam[3:44]。

嵌套算术运算有点棘手。在您的3个示例中，只有第2个示例通过了PEP8验证：

[me@home]$ pep8 <(echo "spam[ham(66)//3:44+eggs()]")
/dev/fd/63:1:13: E225 missing whitespace around operator

[me@home]$ pep8 <(echo "spam[ham(66) // 3:44 + eggs()]")  # OK

[me@home]$ pep8 <(echo "spam[ham(66) // 3 : 44 + eggs()]")
/dev/fd/63:1:18: E203 whitespace before ':'

然而，我发现上述所有内容乍一看都难以解析。

为了便于阅读和遵守PEP8，我个人会选择：

 spam[(ham(66) // 3):(44 + eggs())]

或者更复杂的操作：

 s_from = ham(66) // 3 
 s_to = 44 + eggs()
 spam[s_from:s_to]

Answer 2

我确实看到PEP8中使用的切片：

    - Use ''.startswith() and ''.endswith() instead of string slicing to check
      for prefixes or suffixes.

      startswith() and endswith() are cleaner and less error prone.  For
      example:

        Yes: if foo.startswith('bar'):

        No:  if foo[:3] == 'bar':

我不会称之为明确的，但它会支持你（和我）的理解：

spam[3:5]   # OK

至于在更复杂的情况下使用哪个，我会使用＃3。我不认为在这种情况下，:方法的无空格看起来不错：

spam[ham(66) / 3:44 + eggs()]   # looks like it has a time in the middle. Bad.

如果您希望:更突出，请不要牺牲操作员间距，为:添加额外的空格：

spam[ham(66) / 3  :  44 + eggs()]   # Wow, it's easy to read!

我不会使用＃1因为我喜欢运算符间距，而＃2看起来太像字典key: value语法。

我也不会称之为运营商。它是构造slice对象的特殊语法 - 您也可以

spam[slice(3, 5)]

Answer 3

我同意你的第一个例子。对于后者：PEP 20。可读性很重要。复杂切片表达式在语义上最重要的部分是切片操作符本身，它将表达式分为两部分，应分别解析（由人类读者和解释器）。因此，我的直觉是应该牺牲与PEP 8的一致性，以突出:运算符，即。通过用例子3中的空格包围它。问题是如果省略表达式两边的空格以增加可读性：

1. spam[ham(66)/3 : 44+eggs()]

VS

2. spam[ham(66) / 3 : 44 + eggs()]

我发现1.更快解析。

样式，格式化切片运算符

3 个答案: