Python定义小型序列常量用元组、成员判断用集合是否为最佳实践

常量定义选元组还是列表？ #

这属于明确的编码最佳实践，二者不是无差别的选择。

• 从语义匹配度来说：元组是不可变类型，和全大写命名代表的“常量不可修改”语义完全契合，语法层面直接堵死了后续代码误修改常量内容的可能；列表是可变类型，哪怕命名成全大写常量，代码里依然可以随意执行append、pop、元素赋值操作，存在隐性的误改风险。
• 从底层实现来说：CPython会对小型元组做常量复用优化，同内容的元组比列表内存占用更低，加载速度也更快。

两种写法对比如下：
元组常量写法：ORDER_TYPES = (1, 2, 3)
列表常量写法：ORDER_TYPES = [1, 2, 3]

例外情况：如果这个序列本身就需要动态增删元素，那它从设计上就不是常量，这种场景选列表才是合理的，也不应该用全大写格式命名。

做成员判断时用集合是不是更合理？ #

只要你不需要保留序列顺序、不需要存储重复值，核心用途就是做成员包含校验，不管序列长度多少，选集合都是更合理的方案。

• 性能层面：集合的in操作平均时间复杂度是O(1)，元组和列表的in操作是O(n)，哪怕只有3个元素，集合的判断速度也更快，只是长度过短时这个差异小到人体感知不到而已。
• 语义层面：集合本身就是为“成员归属判断”“无重复值集合”场景设计的，其他开发者看到变量被定义为set，不需要读后续逻辑就能立刻明白它的核心用途是做合法性校验，代码可读性更高。

参考实现：

ORDER_TYPES = {1, 2, 3}
order_type = 1
if order_type in ORDER_TYPES:
    # 对应业务逻辑
    pass

例外情况：如果你的常量需要保留元素顺序、存在重复值、或者需要按索引读取元素，就不要硬用集合，选元组即可。

短序列的实际性能差异 #

拿CPython 3.10环境下、长度为3的同内容序列做实际测算：

• 内存占用：元组约72字节，列表约120字节，集合约216字节。元组的内存优势最明显，集合因为要存储哈希表结构，内存开销最高。
• in操作耗时：执行100万次成员判断，集合耗时约0.03秒，元组约0.05秒，列表约0.06秒。序列长度越短，三者的速度差越小，当序列长度超过10之后，集合的速度优势会快速拉开。

这点性能差异在绝大多数业务场景里确实属于感知不到的级别，谈不上必须做的性能优化，但类型选型的核心价值从来不是那点微末的性能提升，而是用语法本身传递代码意图，减少后续维护的理解成本。

通用选型准则 #

• 定义不需要修改、需要保留顺序/支持索引访问、可能存在重复值的常量时，优先选元组，不要用列表
• 定义核心用途为成员校验、不需要顺序和重复值的常量时，不管长度多少，优先选集合
• 只有当序列本身需要动态增删修改时，才选择列表，且这种场景下不要将其命名为全大写常量

内容的提问来源于stack exchange，提问作者SeaChange