Python没有真正的常量，因其设计哲学强调“约定优于强制”，依赖全大写命名等约定而非语法强制，兼顾动态性与简洁性，社区认为责任共担比技术锁更符合工程实际。
Python 没有真正的常量，是因为它的设计哲学强调“约定优于强制”，语言层面不提供不可变绑定的语法机制，而是依赖命名规范和开发者自律来表达“不应被修改”的意图。
语言设计选择：动态性优先
Python 是一门动态类型、运行时绑定的语言。变量名本质上是对象的标签（引用），而非内存地址的固定别名。赋值操作（=）只是让名字指向新对象，语言不阻止你对已命名的对象重新赋值。加入编译期或运行期的常量锁定机制（如 C 的 const 或 Java 的 final），会增加类型系统复杂度，也与 Python “简洁、灵活、易读”的核心目标冲突。
用约定模拟常量：全大写 + 下划线
PEP 8 明确建议：模块级的常量应使用 UPPER_CASE_WITH_UNDERSCORES 命名（如 MAX_CONNECTIONS、PI = 3.14159）。这不产生任何技术限制，但向其他开发者发出清晰信号——这个值在逻辑上不应被修改。多数静态检查工具（如 pylint）会将对全大写变量的重新赋值标记为警告（W0622 或 C0103）。
增强约束的常见做法
虽然不能阻止赋值，但可通过以下方式提高“常量”的健壮性：
立即学习“Python免费学习笔记（深入）”；
- 定义在模块顶层：避免嵌套作用域中意外覆盖；
-
使用
typing.Final（Python 3.8+）：仅用于类型检查（如 mypy），运行时无效，但能配合 IDE 提示错误； -
封装进类或模块的只读属性：例如用
@property返回私有属性，或通过__slots__和自定义__setattr__限制修改（适用于高级场景，但较重）； -
冻结数据类（
dataclass(frozen=True)）：适合一组相关常量组成的结构体，实例化后属性不可改。
为什么没加？——社区共识与实用主义
Python 开发者普遍接受“责任共担”原则：如果某人执意修改 DEFAULT_TIMEOUT，那不是语言该拦住的事，而是代码审查、测试覆盖和团队规范该管的事。历史上曾有 PEP（如 PEP 240，2001 年）提议引入 const 关键字，但被明确拒绝——理由正是“它增加了语法负担，却无法真正防止错误，还可能误导新手以为‘安全’了”。
不复杂但容易忽略：Python 的“常量”本质是沟通契约，不是技术锁。写清楚、查得勤、测得全，比追求语法上的不可变更贴近实际工程需求。
