Python3：内置函数“map”有bug吗？

Question

以下是我使用 Python 3.8.1（在 macOS Mojave 上，10.14.6 上，如 以及其他一些平台上的 Python 3.7（或更早版本））。我是新来的 计算，不知道如何要求改进 语言，但我想我发现了内置的奇怪行为 函数map。

由于代码 next(iter(())) 引发 StopIteration，我希望 从以下代码中获取StopIteration：

tuple(map(next, [iter(())]))

令我惊讶的是，这会默默地返回元组 ()！

所以看起来地图对象的解包在什么时候停止了 StopIteration 来自 next 击中“空”迭代器 由iter(()) 返回。但是，我不认为例外是 处理得当，因为 StopIteration 在“空”之前没有提出 从列表中选择迭代器（被next 命中）。

1. 我是否正确理解了该行为？
2. 这种行为是否有意为之？
3. 这会在不久的将来改变吗？或者我怎样才能得到它？

编辑：如果我以不同的方式解包地图对象，例如list、for-loop、在列表中解包、函数参数解包、set、dict，则行为相似。所以我认为不是tuple 而是map 这是错误的。

编辑：实际上，在 Python 2 (2.7.10) 中，“相同”的代码会引发 StopIteration。我认为这是理想的结果（除了 map 在这种情况下不返回迭代器）。

Answer 1

这不是map 错误。这是 Python 决定依赖异常来控制流的一个丑陋后果：实际错误看起来像正常的控制流。

当map 在iter(()) 上调用next 时，next 引发StopIteration。这个StopIteration 传播出map.__next__ 并进入tuple 调用。这个StopIteration 看起来像map.__next__ 通常会提升以表示地图结束的StopIteration，所以tuple 认为地图只是缺少元素。

这会导致比你看到的更奇怪的后果。例如，当映射函数引发异常时，map 迭代器不会将自身标记为已耗尽，因此您甚至可以在之后继续迭代它：

m = map(next, [iter([]), iter([1])])

print(tuple(m))
print(tuple(m))

输出：

()
(1,)

（CPython map 实现实际上并没有办法将自己标记为耗尽 - 它依赖于底层迭代器。）

这种 StopIteration 问题很烦人，以至于他们实际上 changed generator 处理 StopIteration 来缓解它。 StopIteration 过去通常从生成器中传播出去，但是现在，如果 StopIteration 会从生成器中传播出来，它会被 RuntimeError 替换，因此它看起来不像生成器正常结束。不过，这只影响生成器，不会影响其他迭代器，例如 map。

Answer 2

1. 我是否正确理解了该行为？

不完全是。 map 接受它的第一个参数，一个函数，并将它应用于某个可迭代的每个项目，它的第二个参数，直到它捕获到 StopIteration 异常。这是一个内部异常，用于告诉函数它已到达对象的末尾。如果您手动提升StopIteration，它会看到并停止，然后才有机会处理列表中的任何（不存在的）对象。

Answer 3

我是问题的发布者，我愿意 想在这里总结一下我学到的东西和我的想法 左。 （我不打算将其作为新问题发布。）

在 Python 中，StopIteration 来自 __next__ 方法 iterator 被视为迭代器已到达末尾的信号。 （否则，这是错误信号。）因此，__next__ 迭代器的方法必须捕获所有StopIteration 意味着结束的信号。

使用map(func, *iterables) 形式的代码创建地图对象，其中func 是一个函数，*iterables 代表 对于一个（从 Python 3.8.1 开始）或多个迭代的有限序列。 __next__ 进程有（至少）两种子进程 可能会引发StopIteration的结果地图对象：

1. 其中一个可迭代对象的__next__ 方法在其中的过程 序列*iterables 被调用。
2. 调用参数func的进程。

map 的意图，据我所知，document （或由help(map) 显示）是StopIteration 来自类型 (2) 的子进程不是地图对象的结尾。 但是，地图对象的__next__ 的当前行为是这样的 在这种情况下，它的进程会发出StopIteration。 （我没有 检查它是否真的捕获StopIteration。如果它 确实如此，然后无论如何它都会再次引发StopIteration。）这会出现 我问的问题的原因。

在上面的答案中，user2357112 支持 Monica（让我友好地将名称缩写为“User Primes”）发现了这种丑陋的后果，但回答是 Python 的错， 而不是map's。不幸的是，我在答案中没有找到令人信服的支持这一结论。我怀疑修复map 会更好，但是 出于性能原因，其他一些人似乎不同意这一点。一世 对Python内置函数的实现一无所知 并且无法判断。所以这一点留给了我。尽管如此，User Primes 的回答足够丰富，可以留下左边的问题 现在对我来说不重要了。 （感谢user2357112再次支持莫妮卡！）

顺便说一下，我试图在 User Primes 的评论中发布的代码 答案如下。 （我认为它会在 PEP 479 之前起作用。）

def map2(function, iterable):
    "This is a 2-argument version for simplicity."
    iterator = iter(iterable)
    while True:
        arg = next(iterator) # StopIteration out here would have been propagated.
        try:
            yield function(arg)
        except StopIteration:
            raise RuntimeError("generator raised StopIteration")

下面是一个稍微不同的版本（同样，一个 2参数版本），这可能更方便（发布希望得到 改进建议！）。：

import functools
import itertools

class StopIteration1(RuntimeError):
    pass

class map1(map):
    def __new__(cls, func, iterable):
        iterator = iter(iterable)
        self = super().__new__(cls, func, iterator)
        def __next__():
            arg = next(iterator)
            try:
                return func(arg)
            except StopIteration:
                raise StopIteration1(0)
            except StopIteration1 as error:
                raise StopIteration1(int(str(error)) + 1)
        self.__next__ = __next__
        return self
    def __next__(self):
        return self.__next__()

# tuple(map1(tuple,
#            [map1(next,
#                  [iter([])])]))
# ---> <module>.StopIteration1: 1