Python非ASCII Unicode标识符意外行为及设计原因问询

问题现象 #

运行以下Python代码时出现意外行为：

K = 'K'
𝕂 = '𝕂'
𝚱 = '𝚱'
𝔎 = '𝔎'
𝕶 = '𝕶'
𝓚 = '𝓚'
ᴷ = 'ᴷ'
assert K == 𝕂 == 𝔎 == 𝕶 == 𝓚 == ᴷ
print(f'{K=}, {𝕂=}, {𝚱=}, {𝕶=}, {𝔎=}, {𝓚=}')

代码无断言错误，输出为：

K='ᴷ', 𝕂='ᴷ', 𝚱='𝚱', 𝕶='ᴷ', 𝔎='ᴷ', 𝓚='ᴷ'

用户已了解PEP 3131及Python标识符文档，但未找到相关解释，核心疑问包括：

• 为何视觉不同的Unicode标识符会被视为同一变量？
• 标识符的Unicode字符串比较逻辑为何与字符串字面量不同？
• 该设计的深层原因、优势及背后的实际特性是什么？

补充验证代码及输出 #

用户通过以下代码验证NFKC归一化对标识符的影响：

from unicodedata import normalize as normal
itisasitisRepr = [                char       for char in ['K', '𝕂', '𝚱', '𝔎', '𝕶', '𝓚', 'ᴷ']]
hexintasisRepr = [         f'{ord(char):5X}' for char in itisasitisRepr]
normalizedRepr = [ normal('NFKC', char)      for char in itisasitisRepr]
hexintnormRepr = [         f'{ord(char):5X}' for char in normalizedRepr]
print(itisasitisRepr)
print(hexintasisRepr)
print(normalizedRepr)
print(hexintnormRepr)
print(f"{              'K' ==              '𝕂'  = }")
print(f"{normal('NFKC','K')==normal('NFKC','𝕂') = }")
print(ᴷ == 𝓚, 'ᴷ' == '𝓚') # gives: True, False

输出显示：

• 字符串字面量直接比较结果为False
• 经过NFKC归一化后比较结果为True
• 标识符之间比较结果为True

核心原因与设计逻辑 #

1. 标识符的Unicode归一化规则 #

Python对标识符采用NFKC归一化处理：当解析代码中的标识符时，会自动将其转换为NFKC归一化后的形式，再进行标识符的唯一性判断。也就是说，所有经过NFKC归一化后得到相同字符串的Unicode字符，都会被视为同一个标识符。

你测试的K、𝕂、𝔎、𝕶、𝓚、ᴷ这些字符，经过NFKC归一化后都会映射到同一个字符，因此Python会将它们视为同一个变量名，最终指向同一个内存对象。而𝚱（U+1D6B1）经过NFKC归一化后仍保持自身，所以是独立的变量。

2. 标识符与字符串字面量的差异 #

字符串字面量的比较是基于原始Unicode码点的直接对比，不会自动进行归一化。只有当你显式调用normal('NFKC', ...)时，才会将字符串转换为归一化形式后比较，这就是为什么字面量'ᴷ' == '𝓚'为False，但归一化后为True的原因。

3. 设计的深层原因与优势 #

• 避免视觉混淆导致的bug：很多Unicode字符视觉相似（比如不同字体风格的K），如果允许它们作为不同标识符，很容易让开发者误将它们当成同一个变量，引发难以排查的错误。通过归一化，Python从根源上杜绝了这类问题。
• 遵循Unicode标准规范：NFKC归一化是Unicode标准中用于消除“兼容等价”字符的规则，兼容等价指的是那些在视觉或功能上等价但码点不同的字符（比如带格式的变体、全角半角字符等）。Python采用这一规则，是对Unicode标准的合规实现。
• 提升代码的可移植性：不同环境下对Unicode字符的渲染可能存在差异，但归一化后的标识符在任何支持Unicode的Python环境中都会被一致解析，保证代码的跨平台一致性。

内容的提问来源于stack exchange，提问作者user7711283