python 3.12 主动移除 distutils、sys.maxint 等过时 api，替换为 sys.maxsize、importlib 等现代替代方案；typing.text 等别名被弃用，rawconfigparser.strict=false 参数失效，所有依赖均直接报错或触发警告。
sys.maxint 被移除、configparser.RawConfigParser 的 strict=False 参数被弃用、旧式类型注解（如 typing.Text）不再有效——这些不是“库不支持脚本”，而是 Python 3.12 主动清理了过时的 API 和语法糖，导致依赖它们的旧脚本直接报错。
Python 3.12 主动移除了哪些底层支撑？
它不是兼容性“退步”，而是有计划地砍掉历史包袱：
-
distutils模块被彻底删除 → 依赖setup.py+distutils.core的老构建脚本会抛出ModuleNotFoundError: No module named 'distutils' -
sys.maxint替换为sys.maxsize→ 所有写成if x > sys.maxint:的条件判断直接崩溃 -
typing.Text、typing.AnyStr等别名被标记为废弃并最终移除 → 使用它们的类型提示在 3.12 下触发DeprecationWarning，部分严格模式下直接报错
为什么自动化脚本特别容易中招？
这类脚本往往长期无人维护，且高度依赖隐式行为和“能跑就行”的惯性写法：
Secure Python Code Sandbox
下载
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
- 硬编码
sys.maxint做边界判断（如 LinuxCNC 的弧线容差逻辑） - 用
RawConfigParser(strict=False)容忍配置文件格式错误（常见于嵌入式或工业控制场景） - 在字符串拼接中滥用 PEP 701 的新 f-string 语法（如
f"{x = }"），但旧版 Black 或 AST 工具尚未适配解析规则
如何快速识别脚本是否踩坑？
别等运行失败，先做静态扫描：
- 运行
python -Wdefault::DeprecationWarning -c "import your_script"，看是否输出警告 - 检查是否有
from distutils.* import *或import distutils—— 这类导入现在必然失败 - 搜索代码里是否出现
sys.maxint、typing.Text、RawConfigParser.*strict.*=False这类关键词
真正麻烦的不是改几行代码，而是有些脚本嵌在 C 扩展模块的 Python 绑定层里（比如 KLayout 的 pymod 或 binwalk 的 uefi_firmware），改完 Python 层还得同步更新 C 接口定义。这种耦合一旦存在，就很难靠单纯升级 pip 包解决。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
