列表比较和元素赋值的奇怪之处 [英] An oddity in list comparison and element assignment

问题描述

以下脚本让我感到困惑。它创建两个嵌套列表，

相同。在完成相同的元素分配后，列表

是不同的。在一种情况下，替换单个元素。在

其他中，整个列都被替换。


-------------------- -------------------------------------------------- -----------------


'''''

列表行为的一个奇怪之处列表发生在

Python 2.4.3（＃69，2006年3月29日，17：35：34）[MSC v.1310 32位（英特尔）]
win32上的
。

未在其他平台或版本上测试。

'''''

a = [[[1,2]，[1， 2]]，[[1,2]，[1,2]]]

b = [[范围（1,3）] * 2] * 2

断言（a == b）

print"最初，python报告列表相等

a [1] [1] = [5]

b [1] [1] = [5]

尝试：

断言（a == b）
除了AssertionError之外的
：

print"在相同的元素分配后，列表不相等

print" a is now，a

print" b现在是，b

----------------------------------- --------------------------------------------------


这是我系统的输出。


---------------- -------------------------------------------------- ------------------

最初，python报告列表是相等的

在相同的元素分配后，列表不相等

a现在是[[[1,2]，[1,2]]，[[1,2]，[5]]]

b现在是[[[1,2]，[5]]，[[1,2]，[5]]]

---------- -------------------------------------------------- ------------------------


这似乎违背了我的一个基本期望，即

对象在相同的

操作后必须保持相等。我认为必须发生的是''b''列表

包含复制的引用而不是[range（1,3）] * 2的副本。

IMO，python'= =运算符应检测列表

结构中的这种差异，因为它会导致元素

赋值下的不同行为。


Mike Ellis

The following script puzzles me. It creates two nested lists that
compare identically. After identical element assignments, the lists
are different. In one case, a single element is replaced. In the
other, an entire column is replaced.

---------------------------------------------------------------------------------------

''''''
An oddity in the behavior of lists of lists. Occurs under
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
on win32.
Not tested on other platforms or builds.
''''''
a =[[[1,2],[1,2]],[[1,2],[1,2]]]
b = [[range(1,3)]*2]*2
assert(a==b)
print "Initially, python reports that the lists are equal"
a[1][1]=[5]
b[1][1]=[5]
try:
assert(a==b)
except AssertionError:
print "After identical element assignments, the lists are not equal"
print "a is now ", a
print "b is now ", b
-------------------------------------------------------------------------------------

Here''s the output on my system.

------------------------------------------------------------------------------------
Initially, python reports that the lists are equal
After identical element assignments, the lists are not equal
a is now [[[1, 2], [1, 2]], [[1, 2], [5]]]
b is now [[[1, 2], [5]], [[1, 2], [5]]]
------------------------------------------------------------------------------------

This seems contrary to one of my fundamental expectations, namely that
objects which compare equally must remain equal after identical
operations. I think what must be going on is that the ''b'' list
contains replicated references instead of copies of [range(1,3)]*2 .
IMO, python''s == operator should detect this difference in list
structure since it leads to different behavior under element
assignments.

Mike Ellis

推荐答案

< mi ************* @ gmail。 COM>写道：

...

<mi*************@gmail.com> wrote:
...

操作。我认为必须发生的是''b''列表
包含复制的引用而不是[range（1,3）] * 2的副本。


正确。

IMO，python'的==运算符应检测列表
结构中的这种差异，因为它会导致元素下的不同行为
任务。

operations. I think what must be going on is that the ''b'' list
contains replicated references instead of copies of [range(1,3)]*2 .
Right.
IMO, python''s == operator should detect this difference in list
structure since it leads to different behavior under element
assignments.

错误;平等并不意味着对身份的任何检查。您可以考虑

list A equals list B的定义。 as：


- len（A）== len（B），AND，

- 对于每个有效索引i，A [i] = = B [i]


这是对平等的非常自然的定义。对于容器：

他们有EQUAL项目 [[以相同的顺序，对于

订单相关的容器]]。在这个非常自然的定义中没有任何地方可以使用物品的IDENTITY来发挥作用。


因此，您对项目变更影响的期望（对于

可变项目）没有根据。


尝试简明扼要地表达你的应该 - 建设性地，作为伪代码

，可以用来检查你的强化平等，而不是

抽象的约束条款 - 以及是否（因为我强烈怀疑）你

找不到一个简单，简洁和自然的定义，如上面的

双线，这可能有助于说服你，你想要的

定义不是最明显，最自然和最基本的，因此不适合选择语言'b
核心的一部分。实际上，编码是一个有趣的问题，如果一个人想要任何

的一般性（例如，不可变项目的身份_物品或

属性又是不可变的_即使对于你的强化平等而言也许并不重要......但这很难表达！ - ）。

Alex

Wrong; equality does not imply any check on identity. You can consider
the definition of "list A equals list B" as:

-- len(A) == len(B), AND,
-- for each valid index i, A[i] == B[i]

This is an extremely natural definition of "equality" for containers:
"they have EQUAL items" [[in the same order, for containers for which
order is relevant]]. Nowhere in this extremely natural definition does
the IDENTITY of the items come into play.

Therefore, your expectations about the effects of item alterations (for
alterable items) are ill-founded.

Try concisely expressing your "should" -- constructively, as pseudocode
that one could use to check for your "strengthened equality", not in
abstract terms of constraints -- and if (as I strongly suspect) you
cannot find a definition that is as simple, concise and natural as the
two-liner above, this might help convince you that your desired
definition would NOT be the most obvious, natural and fundamental, and
therefore would not be appropriate to pick as part of the language''s
core. Indeed, it''s an interesting problem to code up, if one wants any
generality (for example, identity of immutable items _whose items or
attributes are in turn immutable_ probably should not matter even for
your "strengthened" equality... but that''s pretty hard to express!-).
Alex

您好Alex，

我非常尊重您在Python

社区中当之无愧的地位，我'我不相信在相同的操作中平等不应该意味着不变性。


也许最基本的概念是数学是左边和

在对双方进行任何操作后，方程式的右侧保持相同。

。我们对物理世界的体验是相似的。如果我对两辆相同的b / b
汽车的发动机进行相同的修改，我预计性能上的差异是相同的。

如果我的期望如果遇到这种情况，我会断言两辆车的价格与开头不一样，或者说我的改装不是相同的。


至于容器，你会说包含五个

Hi Alex,
With all due respect to your well-deserved standing in the Python
community, I''m not convinced that equality shouldn''t imply invariance
under identical operations.

Perhaps the most fundamental notion is mathematics is that the left and
right sides of an equation remain identical after any operation applied
to both sides. Our experience of the physical world is similar. If I
make identical modifications to the engines of two identical
automobiles, I expect the difference in performance to be identical.
If my expectation is met, I would assert that either the two vehicles
were not identical to begin with or that my modifications were not
performed identically.

As to containers, would you say that envelope containing five

100

账单的信封与包含单个

100
bills is the same as an envelope containing a single

<的信封相同BR />

这篇关于列表比较和元素赋值的奇怪之处的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！