Python 2 中 L 后缀是强制类型标记，用于声明任意精度 long 类型；Python 3 统一为 int 并移除 L 后缀，其存在已无语义基础，保留会导致语法错误。
Python 2 的 L 后缀是类型显式标记，不是可选语法糖
在 Python 2 中，int 是固定宽度（如 32 或 64 位）的整数类型，超出范围会溢出；而 long 是任意精度类型，用后缀 L 或 l 显式声明，例如 12345678901234567890L。这种区分是强制性的：不加 L 就可能因溢出报错或静默转为 long（取决于上下文），加了则明确告诉解释器“请按长整型处理”。
常见错误现象包括：
- 在 Python 2 中写
2**64可能触发OverflowError（取决于平台），但写成2**64L就能成功 - 用
repr()输出long值时总会带L，比如repr(1000000000000L)返回'1000000000000L' - 某些序列化逻辑（如旧版 pickle、正则匹配数字字面量）依赖这个后缀做类型判断
Python 3 废除 long 类型，L 失去存在基础
Python 3 统一所有整数为 int，底层自动切换存储策略（小整数用固定宽度，大整数用动态数组）。这意味着 2**1000、10**100000 全都直接是 int 实例，不再需要用户干预类型选择。
所以 L 后缀被移除不是“简化语法”，而是因为语义已失效：
立即学习“Python免费学习笔记（深入）”；
-
123L在 Python 3 中是语法错误，解析器直接拒绝 —— 它不认识这个后缀 -
repr()和str()都不再输出L，哪怕数值极大，例如str(2**200)就是纯数字字符串 - 任何试图兼容 Python 2 的
L写法（如从配置文件读取、动态 exec）在 Python 3 下都会SyntaxError: invalid syntax
迁移时最常踩的坑：硬编码字面量和字符串解析
很多老项目把数字当字符串存，再用 eval() 或正则提取，比如日志里记录 "count=12345678901234567890L"，或配置项写成 MAX_ID = 9223372036854775807L。这类代码在 Python 3 下直接挂掉。
实操建议：
- 用
ast.literal_eval()替代eval()，它天然拒绝带L的字面量，提前暴露问题 - 正则匹配整数字面量时，去掉对
[Ll]的捕获组，例如把r'\d+[Ll]?'改成r'\d+' - 若必须兼容双版本，用字符串替换预处理：
s.replace('L', '').replace('l', '')，再交给int()解析
int() 构造函数在两版中行为一致，但源头输入不能含 L
int("12345678901234567890") 在 Python 2 和 3 中都返回正确整数，且类型分别是 int 和 long（2）或 int（3）。但 int("12345678901234567890L") 在任一版本都会报 ValueError: invalid literal —— 因为 int() 本身就不支持后缀。
这说明：后缀只存在于源码字面量层面，不进入运行时数值对象。真正要警惕的是那些把字面量当原始字符串处理的场景，比如模板生成、AST 操作、宏替换等。
最容易被忽略的一点：有些 C 扩展模块或 Cython 代码里手动检查 PyLong_Check()，在迁移到 Python 3 后可能漏掉对 PyLong_CheckExact() 的调整，导致类型判断失效 —— 虽然值是 int，但它的 C 层类型对象已经不是以前的 PyLong_Type 了。
