当前位置: 首页 > 面试题库 >

是否保证python字典中的keys()和values()的顺序相同?[重复]

宋琛
2023-03-14
问题内容

这个问题已经在这里有了答案

Python字典:keys()和values()总是顺序相同吗? (8个答案)

7年前关闭。

本机内置的python dict是否保证以相同的方式对keys()values()列表进行排序?

d = {'A':1, 'B':2, 'C':3, 'D':4 } # or any other content
otherd = dict(zip(d.keys(), d.values()))

我一直有d == otherd吗?

不管是对还是错,我对这个问题上的任何参考指针都感兴趣。

PS:我了解上述属性并非对每个行为像字典的对象都是正确的,我只是想知道内置的字典。当我进行测试时,看起来好像是真的,这也就不足为奇了,因为具有相同的顺序keys()并且values()可能是最简单的实现。但是我想知道是否明确定义了此行为。


问题答案:

键和值以任意顺序列出,该顺序是非随机的,在Python实现中会有所不同,并且取决于字典的插入和删除历史。如果items()keys()values()iteritems()iterkeys(),和itervalues()被称为中间没有修改的字典,列表会直接对应。

从的文档中dict



 类似资料:
  • 问题内容: 看起来字典的和方法返回的列表始终是一对一映射(假设在调用这两种方法之间字典没有改变)。 例如: 如果你没有在调用keys()和调用之间更改字典values(),那么假设上述for循环将始终显示True是否错误?我找不到任何证明文件。 问题答案: 发现了这一点: 如果,, ,和 被称为中间没有修改的字典,列表会直接对应。 在2.x文档和3.x文档上。

  • 问题内容: 我有一本按照特定顺序声明的字典,并希望一直保持该顺序。实际上不能根据它们的值按顺序保留,我只希望按声明的顺序保留。 因此,如果我有字典: 如果我查看它或遍历它,则不是按此顺序进行的,有什么方法可以确保Python保持我声明键/值的显式顺序? 问题答案: 从Python 3.6开始,标准类型默认会保留插入顺序。 定义 将产生字典,字典中的键按源代码中列出的顺序排列。 这是通过对稀疏哈希表

  • 问题内容: 码: 打印。我不确定该方法如何确定l中关键字的顺序。但是,我希望能够以“适当”的顺序检索关键字。当然,正确的顺序将创建列表。 和这个: 问题答案: 你可以使用OrderedDict(需要Python 2.7)或更高版本。 另外,请注意,由于dict你使用进行创建的操作已经忘记了元素的顺序,因此该操作无效。相反,你想使用。 如文档中所述,对于低于python 2.7的版本,你可以使用此配

  • 问题内容: 我正在寻找一个有序的关联数组,即有序的字典的可靠实现。我想要按键而不是插入顺序排序。 更准确地说,我正在寻找一种int-to-float(或另一种用例是string-to-float)映射结构的节省空间的实现,该结构的结构是: 有序迭代为O(n) 随机访问为O(1) 我想到的最好的方法是将字典和键列表粘合在一起,使最后一个键按等分和插入顺序排列。 还有更好的主意吗? 问题答案: “随机

  • 问题内容: 我认为使用某种顺序才有意义。我想做的是在视图中包括该子句,以便该视图上的所有s都可以忽略它。但是,我担心该订单不一定会延续到,因为它没有指定订单。 是否存在一种情况,即视图指定的顺序不会反映在该视图上的select结果中(该视图中的order by子句除外)? 问题答案: 您不能指望没有显式子句的任何查询中的行顺序。如果查询有序视图,但没有包括子句,则如果它们的顺序正确,请感到惊喜,并

  • 问题内容: 在C语言中,在结构中定义字段的顺序是在内存中实例化它们的顺序。考虑到内存对齐,以下结构在内存中的大小将为8个字节,如图所示,但是如果将字段反转,则只有6个字节,因为不需要任何对齐填充。 这种顺序保证存在于C结构,C ++类(和结构)和Objective-C类中。 Swift类和结构中的字段是否同样保证了存储顺序?或者(鉴于该语言不支持与列出的其他指针相同的指针),编译器是否在编译时为您

  • 下面的代码安全吗?编写类似这样的代码可能很有诱惑力: 该映射仅用于字符串文本。 我认为这是完全合法的,似乎正在起作用,但是我从未见过保证在两个不同地方使用的文字指针是相同的。我无法设法让编译器为具有相同内容的文本生成两个单独的指针,所以我开始怀疑这个假设有多坚定。 我只关心相同内容的文字是否可以有不同的指针。或者更正式地说,上面的代码可以除外吗? 我知道有一种方法可以编写代码来确保它有效,我认为上

  • 的Javadoc表示(强调是我的): 此操作的行为显式不确定。对于并行流管道,此操作不能保证尊重流的相遇顺序,因为这样做会牺牲并行性的好处。对于任何给定的元素,操作可以在库选择的任何时间和线程中执行。如果操作访问共享状态,则它负责提供所需的同步。 同样的文本也出现在Java9早期访问Javadoc中。 如果forEach不保留遭遇顺序,则会引入bug。在报告针对NetBeans的bug之前,我想知