字典理解中的操作顺序_python

我遇到了以下有趣的结构：

假设您有一个列表列表如下：

my_list = [['captain1', 'foo1', 'bar1', 'foobar1'], ['captain2', 'foo2', 'bar2', 'foobar2'], ...]

并且你想用0 index元素作为键来创建一个字典。 一个方便的方法是：

my_dict = {x.pop(0): x for x in my_list}
# {'captain1': ['foo1', 'bar1', 'foobar1'], ...}

看起来， pop在列表x的赋值之前作为值，这就是为什么'captain'没有出现在值中（它已经弹出）

现在让我们更进一步，尝试获得如下结构：

# {'captain1': {'column1': 'foo1', 'column2': 'bar1', 'column3': 'foobar1'}, ...}

为此，我写了以下内容：

my_headers = ['column1', 'column2', 'column3']
my_dict = {x.pop(0): {k: v for k, v in zip(my_headers, x)} for x in my_list}

但是这会返回：

# {'captain1': {'col3': 'bar1', 'col1': 'captain1', 'col2': 'foo1'}, 'captain2': {'col3': 'bar2', 'col1': 'captain2', 'col2': 'foo2'}}

所以这种情况下的pop会在构造内部字典之后发生（或者至少在zip ）。

怎么可能？ 这是如何运作的？

问题不是关于如何做到这一点，而是为什么会出现这种行为。

我使用的是Python 3.5.1版。

注意：从Python 3.8和，这已经改变，并且首先评估密钥。

tl; dr直到Python 3.7 ：尽管Python 确实首先评估了值（表达式的右侧），但根据和以及的 这似乎是 （C）Python中的错误 。

虽然之前，其中值在键之前再次进行了评估， 但修补程序未修改为包含字典理解。 。

根据参考手册，Python 从左到右评估表达式 ，从右到左评估分配 ; dict-comprehension实际上是一个包含表达式的表达式， 而不是赋值 ^* ：

{expr1: expr2 for ...}

其中，根据的相应可以预期expr1: expr2评估方式与它在显示中的作用类似。 因此，两个表达式都应遵循定义的顺序， expr1应该在expr2之前计算（如果expr2包含它自己的表达式，它们也应该从左到右进行计算。）

dict-comps上的PEP还声明以下内容应在语义上等效：

dict理解的语义实际上可以通过将列表理解传递给内置字典构造函数来体现在Python 2.2中：

>>> dict([(i, chr(65+i)) for i in range(4)])

在语义上等同于：

>>> {i : chr(65+i) for i in range(4)}

是元组(i, chr(65+i))按预期从左到右进行评估。

当然，将此更改为根据表达式规则进行操作会在创建dict产生不一致。 字典理解和带有赋值的for循环会产生不同的评估顺序，但这很好，因为它只是遵循规则。

虽然这不是一个主要问题，但应该修复（评估规则或文档）来消除歧视情况。

^*在内部，这确实会导致对字典对象的赋值，但是这不应该破坏表达式应该具有的行为。 用户对表达式应如参考手册中所述的行为有所期望。

正如其他回答者指出的那样，由于你在其中一个表达式中执行了一个变异动作，所以你要先删掉任何被评估的信息; 正如Duncan所做的那样，使用print电话可以了解所做的事情。

有助于显示差异的功能：

def printer(val):
    print(val, end=' ')
    return val

（固定）字典显示：

>>> d = {printer(0): printer(1), printer(2): printer(3)}
0 1 2 3

（奇数）字典理解：

>>> t = (0, 1), (2, 3)
>>> d = {printer(i):printer(j) for i,j in t}
1 0 3 2

是的，这适用于C Python。 我不知道其他实现如何评估这种特定情况（尽管它们都应该符合Python参考手册。）

挖掘源代码总是很好（你也可以找到描述行为的隐藏注释），所以让我们看一下文件的compiler_sync_comprehension_generator ：

case COMP_DICTCOMP:
    /* With 'd[k] = v', v is evaluated before k, so we do
       the same. */
    VISIT(c, expr, val);
    VISIT(c, expr, elt);
    ADDOP_I(c, MAP_ADD, gen_index + 1);
    break;

这似乎是一个足够好的理由，如果判断为这样，则应归类为文档错误。

在我做的快速测试中，切换这些语句（ VISIT(c, expr, elt);先访问）同时切换（用于dict-comps）中的相应：

TARGET(MAP_ADD) {
    PyObject *value = TOP();   # was key 
    PyObject *key = SECOND();  # was value
    PyObject *map;
    int err;

结果是基于文档的评估结果，在值之前评估密钥。 （不是因为它们的异步版本，那是另一个需要的开关。）

~~我会对这个问题发表评论，并在有人回复我时更新。~~

创建在跟踪器上。 将在进展时更新问题。

看起来，pop在列表x的赋值之前作为值，这就是为什么'captain'没有出现在值中（它已经弹出）

不，它发生的顺序是无关紧要的。 您正在改变列表，这样您就可以在弹出窗口后看到修改后的列表。 请注意，通常您可能不希望这样做，因为您将销毁原始列表。 即使这次无关紧要，也是未来不知情的陷阱。

在这两种情况下，首先计算值侧，然后计算相应的键。 只是在你的第一种情况下它并不重要，而它在第二种情况下。

你很容易看到这个：

>>> def foo(a): print("foo", a)
... 
>>> def bar(a): print("bar", a)
... 
>>> { foo(a):bar(a) for a in (1, 2, 3) }
('bar', 1)
('foo', 1)
('bar', 2)
('foo', 2)
('bar', 3)
('foo', 3)
{None: None}
>>>

请注意，您不应该编写依赖于首先评估的值的代码：在将来的版本中，行为可能会发生变化（在某些地方有人说在Python 3.5及更高版本中已经改变了，但事实上似乎并非如此）。

一种更简单的方法，可以避免改变原始数据结构：

my_dict = {x[0]: x[1:] for x in my_list}

或者你的第二个例子：

my_headers = ['column1', 'column2', 'column3']
my_dict = {x[0]: {k: v for k, v in zip(my_headers, x[1:])} for x in my_list}

要回答注释：zip使用原始x因为它在pop之前被评估，但是它使用列表的内容来构造新列表，因此在结果中看不到对列表的任何后续更改。 第一个理解也使用原始的x作为值，但它然后改变列表，因此值仍然看到原始列表，因此突变。

正如我在评论中所说的那样，因为在词典中理解python首先评估该值。 作为一种更加pythonic的方法，您可以使用解包变量来完成此任务，而不是在每次迭代中从列表中弹出：

In [32]: my_list = [['captain1', 'foo1', 'bar1', 'foobar1'], ['captain2', 'foo2', 'bar2', 'foobar2']]

In [33]: {frist: {"column{}".format(i): k for i, k in enumerate(last, 1)} for frist, *last in my_list}
Out[33]: 
{'captain2': {'column3': 'foobar2', 'column1': 'foo2', 'column2': 'bar2'},
 'captain1': {'column3': 'foobar1', 'column1': 'foo1', 'column2': 'bar1'}}

关于python在评估字典理解中的键和值时的奇怪行为，经过一些实验后我意识到这种行为在某种程度上是合理的而不是一个bug。

我会在以下部分中减掉我的印象：

在赋值表达式中，python首先计算右侧。 来自doc：

Python从左到右评估表达式。 请注意，在评估分配时，右侧在左侧之前进行评估。
字典理解是一个表达式，将从左到右进行评估，但由于在通过python进行翻译后，在引擎盖下有一个赋值。 将首先评估具有权利的一方的价值。
例如以下理解：
{b.pop(0): b.pop(0) for _ in range(1)}与以下代码段相同：

def dict_comprehension():
    the_dict = {}
    for _ in range(1):
        the_dict[b.pop(0)] = b.pop(0)
    return the_dict

这里有些例子：

In [12]: b = [4, 0]

# simple rule : Python evaluates expressions from left to right.
In [13]: [[b.pop(0), b.pop(0)] for _ in range(1)]
Out[13]: [[4, 0]]

In [14]: b = [4, 0]
# while evaluating an assignment (aforementioned rule 1), the right-hand side is evaluated before the left-hand side.
In [15]: {b.pop(0): b.pop(0) for _ in range(1)}
Out[15]: {0: 4}

In [16]: b = [4, 0]
# This is not a dictionary comprehension and will be evaluated left to right.
In [17]: {b.pop(0): {b.pop(0) for _ in range(1)}}
Out[17]: {4: {0}}

In [18]: b = [4, 0]
# This is not a dictionary comprehension and will be evaluated left to right.
In [19]: {b.pop(0): b.pop(0) == 0}
Out[19]: {4: True}

In [20]: b = [4, 0]
# dictionary comprehension.
In [21]: {b.pop(0): {b.pop(0) for _ in range(1)} for _ in range(1)}
Out[21]: {0: {4}}

关于事实（或者更好地说抽象）之间的差异，字典理解是表达式，应该从左到右（基于python文档）评估观察到的行为，我认为它实际上是python文档的问题和不成熟不是python代码中的错误。 因为具有一致的文档而没有任何例外，所以改变功能是不合理的。

实际上，您的观察不需要特殊的操作顺序。 原因是x.pop(0)修改了对象x 。 因此，在这种情况下，无论是在键（ x.pop(0) ）之前还是之后评估值（ x ）都无关紧要。

无论如何，我不认为python语言规范规定了某种操作顺序，这意味着你不应该依赖于任何特定的顺序。

实际上，标准实现恰好在评估密钥之前评估该值，但标准中没有任何地方说明这一点。 唯一的保证是键值对按迭代顺序进行评估，并按顺序插入。

字典理解中的操作顺序

问题描述

1楼

2楼

3楼

4楼