Python 软关键字检查：match 明明列在名单里，为什么仍能作为变量名
给代码生成器做字段命名校验时，把所有“像语法的单词”放进同一张禁用表，看似稳妥，却可能把合法名称全部拒绝。另一种相反的错误是只看isidentifier，看到if返回真就允许它进入赋值语句。名称是否合法至少有字符形式、关键词分类和所在语法位置三个层次，三者应该分别验证。
本文在Linux、Python 3.12.14中使用固定样本实跑。官方文档核验于2026年10月3日；在线文档显示的补丁版本可能不同于这里记录的实际解释器。程序不访问真实业务数据，也不连接远程服务。
AI模型生成的原创概念图：单词卡片在普通赋值入口和特定语法入口中扮演不同角色；用于解释程序模型，不是软件截图、测试截图或实拍照片，精确行为以程序和实际输出为准。
完整程序与实际输出
将下面程序保存为tech09.py，执行python tech09.py。预期出现的异常已在例子里处理；退出码为零才表示本次演示正常完成。
import keyword
for word in ("if", "match", "case", "_", "type", "2items"):
assignment = f"{word} = 7"
try:
compile(assignment, "<name-check>", "exec")
allowed = True
except SyntaxError:
allowed = False
print(word, "identifier=", word.isidentifier(),
"keyword=", keyword.iskeyword(word),
"soft=", keyword.issoftkeyword(word),
"assignment=", allowed)
match = 7
case = "label"
_ = "saved"
type = "alias-name"
match {"kind": "ready"}:
case {"kind": "ready"}:
print("pattern=ready")
print("names=", match, case, _, type)本次实际标准输出：
if identifier= True keyword= True soft= False assignment= False match identifier= True keyword= False soft= True assignment= True case identifier= True keyword= False soft= True assignment= True _ identifier= True keyword= False soft= True assignment= True type identifier= True keyword= False soft= True assignment= True 2items identifier= False keyword= False soft= False assignment= False pattern=ready names= 7 label saved alias-name
第一关只检查名称的字符形状
先看if这一行：identifier为真，assignment却为假。这说明isidentifier只回答字符串是否具备标识符的词法形式，不会替你排除所有语法保留字。与之相对，2items在这一关就失败，因为这样的字符排列不能作为普通名称。用同一份名单并排打印四种判断，比只显示一个“合法”布尔值更容易发现校验规则混淆。
程序在compile中构造的只是固定样本赋值，没有执行生成的代码。compile成功证明这段完整赋值语法能被当前解释器接受；它不保证名字适合业务，也不保证后续表达式安全。面对用户输入时，不能把“能编译”升级成“可以执行”，更不应为了验证名称而直接eval或exec不可信字符串。
软关键字要放进完整语句里理解
match、case和下划线在本次Python 3.12环境中都出现在软关键字名单。它们在特定模式匹配语法中有专门含义，但在示例的普通赋值里仍然可用。程序先保存match等变量，又写出一个真正的match语句；输出pattern=ready以后，names一行仍保留先前保存的普通变量值。这个小实验把“名称分类”和“当前语法角色”分开了。
示例故意使用字面量模式匹配字典，不引入新的捕获变量，避免把变量绑定规则混到词法分类问题里。下划线在普通赋值中保存字符串，也不意味着以后每一个下划线都会读取这个字符串。一个词在特定语句中如何解释，要由语法上下文判断；不能仅凭它是否已经存在于命名空间里决定。
代码生成器应先声明目标版本和位置
本次type同样被识别为软关键字，这是Python 3.12词法环境的一部分。若生成工具运行在一个版本，却为另一个版本输出源文件，只读取当前解释器的名单可能给出错误兼容性结论。实际流水线应明确目标解释器，并在目标版本上执行编译验收；多版本支持则把目标版本组成测试矩阵，不能只保存一份长期不变的关键词表。
如果只生成普通变量赋值，字符形式检查加硬关键字检查通常是基础入口；如果还生成模式、类型别名或其他语句，就需要按具体语法位置处理。若团队为了可读性主动禁用软关键字作变量名，可以这样做，但应把它写成项目命名规范，而不是声称解释器必定拒绝。这样报错信息才能区分语法错误与团队约定。
语法允许之后还要检查可读性
type在示例里被赋成字符串，会遮住同名内置函数。这里这样写只是为了展示语法许可，日常代码更适合用type_name、record_kind等说明用途的名字。同样，match和case虽然能用，也未必是复杂模式处理函数里最清楚的局部变量名。可维护性检查可以比语法更严格，却不应混淆两者的原因。
建议为名称校验保留几类固定样本：普通名称、硬关键字、软关键字、数字开头、非ASCII字母，以及项目自行保留的前缀。每个失败都输出具体规则，最后对完整生成模块做编译和静态检查。这样未来语言新增语法时，更新的是明确的兼容性边界，而不是依赖一条含糊的“名字不合法”。
验证记录与参考资料
本次完整程序退出码为0，标准错误为空。名称分类与编译结果针对列出的Python版本和固定语句；其他语法位置及目标版本需要分别验证。
