Python tokenize.untokenize 为什么不能保证恢复原始空格

tokenize.untokenize 保证的是重新分词后 token 的类型与文本能够对应，而不是输出源码与原文件逐字节相同。普通 token 之间的空格可能重新安排，所以把它当成源码的“解压还原器”使用，容易得到意外的 diff。

官方文档：https://docs.python.org/3/library/tokenize.html

用最小例子区分两种相等

下面先保留 token 的类型和文本，再重新拼成源码。比较结果时，分别看字符串是否相同以及重新分词后的二元序列是否相同，不把两种结果混成一个判断。

import io
import tokenize

source = "total  =  7 +  5\n"

def token_pairs(text):
    # 保留词法身份，主动丢弃行列坐标和原始行字段。
    return [
        (item.type, item.string)
        for item in tokenize.generate_tokens(io.StringIO(text).readline)
    ]

pairs = token_pairs(source)
rebuilt = tokenize.untokenize(pairs)

# repr 让普通空格和换行差异可见，不预设具体版本的排版。
print(repr(source))
print(repr(rebuilt))
print(source == rebuilt)
print(pairs == token_pairs(rebuilt))

这个例子供读者观察差异，不把某一种重建字符串当作跨版本固定输出。重要的是：二元 token 序列保留了哪些词法单元，却没有保存每两个单元之间原来用了几个空格。信息已丢失，拼接时就需要重新安排分隔。

区分词法信息与源码排版

完整的 TokenInfo 含有 type、string、start、end 和 line。type 表示类别，string 表示 token 文本；start/end 记录行列位置，line 带有来源行。普通间隔空白通常不是独立 token，但这不意味着 Python 的所有空白都不重要：缩进、逻辑换行等具有专门的词法记录。

例如字符串字面量内部的空格属于 token 文本，和赋值号两边的间隔不是同一种信息。不要为了“修正空白”直接对整个源码做空白替换，那样可能改变字符串内容、注释或缩进。

保留完整记录也不要承诺字节还原

把完整 TokenInfo 传给 untokenize，可以保留更多位置线索，常见输入的排版会更接近原文。但这仍不构成对原始字节的通用承诺。当前实现存在使用坐标补空白的逻辑；坐标能说明距离，却不能普遍表达原处到底是空格还是制表符。

文档对扩展字段的简述也不能当作原始文件保真承诺。实际维护工具应依据公开的类型与文本往返保证设计，而不是依赖某个实现版本恰好保留了多少空格。尤其在修改 token 长度之后，旧坐标未必仍然适用，位置冲突还可能引发异常。

按保真目标选择保存方式

如果工具允许统一格式，保留需要的 token，改写后重新生成源码，再由项目采用的格式策略处理即可。如果只想改一个名称并尽量保留其他字符，应保存原始文本，以明确范围做局部替换，而不是重建整份文件。

构造文本补丁时，必须正确处理行列到文本位置的转换。tokenize 的列位置按 Unicode 码点计数，不能直接当作 UTF-8 字节偏移；制表符也不能简单视作若干显示列。多处修改应基于同一原始快照计算，避免前一次替换改变后续位置。

处理编码与输入边界

tokenize() 接收字节行并产生编码 token；generate_tokens() 接收文本行，不产生 ENCODING。untokenize 的输入中存在编码 token 时返回 bytes，否则返回 str。文件保存时应先弄清返回值类型，再选择二进制或文本写入方式。

注释能保留吗？tokenize 会返回注释 token，但主动过滤掉以后，untokenize 无法替你恢复。重新分词相同能证明程序行为完全一样吗？它回答的是词法对应关系，不能代替业务行为判断。能用它修复任意损坏源码吗？不应如此依赖，官方说明该模块按语法有效的 Python 源码设计，对无效代码的行为没有通用保证。

对源码工具而言，先确定要保留的是词法身份、可读格式，还是原始字节，再选择保存材料，通常比追逐某一处多出来的空格更有用。