列表与元组，何时使用？[重复]-IT科技

列表与元组，何时使用？[重复]

2025-02-28 08:23:00

admin

原创

摘要：问题描述：在 Python 中，什么时候应该使用列表，什么时候应该使用元组？有时候你别无选择，例如如果你有"hello %s you are %s years old" % x 那么 x 一定是一个元组。但是如果我是设计 API 并选择数据类型的人，那么指导原则是什么？解决方案 1：元组本...

问题描述：

在 Python 中，什么时候应该使用列表，什么时候应该使用元组？

有时候你别无选择，例如如果你有

"hello %s you are %s years old" % x

那么 x 一定是一个元组。

但是如果我是设计 API 并选择数据类型的人，那么指导原则是什么？

解决方案 1：

元组本质上是固定大小的，而列表是动态的。

换句话说，atuple是不可变的，而 alist是可变的。

不能向元组添加元素。元组没有附加或扩展方法。
不能从元组中删除元素。元组没有 remove 或 pop 方法。
您可以在元组中找到元素，因为这不会改变元组。
您还可以使用in运算符来检查元组中是否存在某个元素。

元组比列表更快。如果您要定义一组常量值，并且您要对其进行的所有操作就是对其进行迭代，请使用元组而不是列表。
如果对不需要更改的数据进行“写保护”，代码会更安全。使用元组而不是列表就像有一个隐含的断言语句，即该数据是常量，需要特殊的想法（和特定函数）来覆盖它。
某些元组可用作字典键（具体来说，包含不可变值的元组，如字符串、数字和其他元组）。列表永远不能用作字典键，因为列表是可变的。

来源：深入 Python 3

解决方案 2：

有一种强烈的文化认为元组用于异构集合，类似于struct在 C 中使用 s ，列表用于同构集合，类似于数组。但我从来没有完全理解这与其他答案中提到的可变性问题。可变性是有约束力的（你实际上不能改变元组），而同构性不是强制的，所以似乎是一个不那么有趣的区别。

解决方案 3：

我相信（而且我不太精通 Python）主要区别在于元组是不可变的（赋值后不能就地更改）而列表是可变的（可以附加、更改、减去等）。

因此，我倾向于使元组成为分配后不应该改变的东西，而使列表成为可以改变的东西。

解决方案 4：

它必须可变吗？使用列表。它必须不可变吗？使用元组。

否则，这是一个选择的问题。

对于异构对象的集合（例如分为姓名、街道、城市、州和邮政编码的地址），我更喜欢使用元组。它们总是可以轻松升级为命名元组。

同样，如果要迭代集合，我更喜欢列表。如果它只是一个将多个对象作为一个整体保存的容器，我更喜欢元组。

解决方案 5：

您需要决定的第一件事是数据结构是否需要可变。如前所述，列表是可变的，而元组则不是。这也意味着元组可以用作字典键，而列表不能。

根据我的经验，元组通常用于顺序和位置有意义且一致的地方。例如，在为选择自己的冒险游戏创建数据结构时，我选择使用元组而不是列表，因为元组中的位置是有意义的。以下是该数据结构的一个示例：

pages = {'foyer': {'text' : "some text", 
          'choices' : [('open the door', 'rainbow'),
                     ('go left into the kitchen', 'bottomless pit'),
                     ('stay put','foyer2')]},}

元组中的第一个位置是用户玩游戏时显示的选择，第二个位置是选择所指向的页面的键，这对于所有页面都是一致的。

元组的内存效率也比列表更高，尽管我不确定这种好处何时会显现出来。

另请查看《Think Python》中有关列表和元组的章节。

解决方案 6：

但是如果我是设计 API 并选择数据类型的人，那么指导原则是什么？

对于输入参数，最好接受最通用的接口来满足您的需要。它很少只是一个元组或列表 - 更常见的是序列、可切片甚至可迭代。除非您明确检查输入类型，否则 Python 的鸭子类型通常会免费获得它。除非绝对不可避免，否则不要这样做。

对于您生成的数据（输出参数），只需返回最方便的数据，例如返回您保留的任何数据类型或您的辅助函数返回的任何数据类型。

要记住的一件事是避免返回属于你的状态的列表（或任何其他可变内容），例如

class ThingsKeeper
    def __init__(self):
        self.__things = []

    def things(self):
        return self.__things  #outside objects can now modify your state

    def safer(self):
        return self.__things[:]  #it's copy-on-write, shouldn't hurt performance