python - Zen of Python : Errors should never pass silently. 为什么 zip 会这样工作？

Question

我在我的代码中经常使用 python 的函数 zip(主要是为了创建如下所示的字典)

dict(zip(list_a, list_b)) 

我发现它真的很有用，但有时它会让我感到沮丧，因为我最终会遇到 list_a 与 list_b 的长度不同的情况。 zip 只是继续并将两个列表压缩在一起，直到它获得一个与较短列表长度相同的压缩列表，忽略较长列表的其余部分。在大多数情况下，这似乎应该被视为错误，根据 python 的禅宗，它永远不应该默默地通过。

鉴于这是一个不可或缺的功能，我很好奇为什么要这样设计？如果您尝试将两个不同长度的列表压缩在一起，为什么不将其视为错误？

Answer 1

原因一:历史原因

zip 允许不等长参数，因为它旨在通过允许 不等长参数改进 map。这种行为是 zip 存在的原因。

这是在 zip 存在之前你是如何做的:

>>> a = (1, 2, 3)
>>> b = (4, 5, 6)
>>> for i in map(None, a, b): print i
...
(1, 4)
(2, 5)
(3, 6)
>>> map(None, a, b)
[(1, 4), (2, 5), (3, 6)]

这非常不直观，并且不支持不等长列表。这是一个主要的设计问题，您可以在 the official RFC proposing zip for the first time 中一目了然。 :

While the map() idiom is a common one in Python, it has several disadvantages:

• It is non-obvious to programmers without a functional programming background.

• The use of the magic None first argument is non-obvious.

• It has arbitrary, often unintended, and inflexible semantics when the lists are not of the same length - the shorter sequences are padded with None :

  >>> c = (4, 5, 6, 7)

  >>> map(None, a, c)

  [(1, 4), (2, 5), (3, 6), (None, 7)]

所以，不，这种行为不会被视为错误 - 这就是它最初设计的原因。

---

原因2:实际原因

因为它非常有用，明确指定并且根本不必将其视为错误。

通过允许不等长度，zip 只要求其参数符合 iterator protocol .这允许 zip 扩展到生成器、元组、字典键以及世界上任何实现 __next__() 和 __iter__() 的东西，正是因为它不询问长度。

这很重要，因为生成器不支持len()，因此无法事先检查长度。添加一个长度检查，你就会破坏 zip 在生成器上工作的能力，而这正是应该的时候。这是一个相当严重的劣势，你不同意吗？

---

原因3:菲亚特

Guido van Rossum 希望这样:

Optional padding. An earlier version of this PEP proposed an optional pad keyword argument, which would be used when the argument sequences were not the same length. This is similar behavior to the map(None, ...) semantics except that the user would be able to specify pad object. This has been rejected by the BDFL in favor of always truncating to the shortest sequence, because of the KISS principle. If there's a true need, it is easier to add later. If it is not needed, it would still be impossible to delete it in the future.

亲吻胜过一切。