【Python笔记】从一段Bug代码来理解Python的Naming Rule

最新推荐文章于 2025-05-26 16:53:33 发布

原创最新推荐文章于 2025-05-26 16:53:33 发布 · 1.5k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#Python

Python 专栏收录该内容

22 篇文章

订阅专栏

本文通过一段简化的Bug代码，深入探讨Python的Naming Rule。代码中`b_dict[sk] = sv`导致对`b_dict`的操作实际上影响了`a_dict`，因为`sv`与`a_dict`关联。此行为符合Python的命名和绑定规则，但可能违背程序员的直觉。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

从Python文档关于Naming and binding的说明可知，变量名是绑定到具体对象的，从这点来看，可以把它理解为C++中的引用。考虑下面两行语句：

a = 'test'
a = 'test_ext'

第1行执行后，Python解释器会在内存中创建string类型的对象'test'，这个对象一旦创建就不能再修改其值。赋值符号只是将变量名a绑定到这个对象上而已。
第2行执行后，同理，值为'test_ext'的string对象被创建出来，变量名a重新绑定到这个新对象上。此时，'test'对象已经无法通过a访问到了。
再次强调：这两行语句的行为与C/C++中的行为完全不同！在C语言中，int a = 1执行后，会创建出名为a且大小为sizeof(int)的内存单元（当然，由于编译器会对内存做alinging优化，所以实际申请的内存大小可能不只sizeof(int)），该内存单元存放int值1，而 a = 2执行后，a代表的内存单元地址不变，其值更新为2。

关于上述Python Naming Rule的行为，我之前写过一篇笔记简单分析过，这里不再赘述。

上述规则单独拿出来分析是容易理解的，但在实际工程项目中，很可能由于疏忽这种“赋值即绑定”的特性给代码引入Bug（有经验的C/C++码农写Python代码时很容易犯这个错误），而这种Bug一旦引入，由于其隐蔽性（因为它隐藏在我（们）认为最不可能出错的地方），想要在成千上万行代码中快速定位是很费时的。是的，Bug就在那里，可偏偏看不出来到底是哪行代码引入的，想想就有点抓狂。。。

本篇笔记的目的就是通过一段简化的Bug代码来加深对这个Naming Rule的理解。

直接上代码（含bug）：

#!/bin/env python
#-*- encoding: utf-8 -*-

def test():
    a_dict = {'a1' : {'s1' : ['foo']}, 'a2' : {'s1' : ['bar']}}
    b_dict = {}
    print 'begin: a_dict=%s' % (a_dict)
    print 'begin: b_dict=%s' % (b_dict)
    for k in a_dict.keys():
        for sk, sv in a_dict[k].items():
            if sk in b_dict:
                b_dict[sk].append(sv)
                b_dict[sk].append('addition')
            else:
                b_dict[sk] = sv
    print 'end: a_dict=%s' % (a_dict)
    print 'end: b_dict=%s' % (b_dict)

    return 0

if '__main__' == __name__:
    test()

上面代码片段的本意是想通过a_dict来构造b_dict，具体而言，a_dict是个2级dict结构，其第2级dict的key作为b_dict的key，若a_dict中存在相同的2级key，则它们的value做merge成list后再append一个'addition'元素，这个最终的list作为b_dict在该2级key下的value。
我们可以思考一下上述代码的执行结果，然后跟实际的运行结果做对比：

begin: a_dict={'a1': {'s1': ['foo']}, 'a2': {'s1': ['bar']}}
begin: b_dict={}
end: a_dict={'a1': {'s1': ['foo', ['bar'], 'addition']}, 'a2': {'s1': ['bar']}}
end: b_dict={'s1': ['foo', ['bar'], 'addition']}

注意上述结果中， a_dict的值也被改变了，这明显不是预期的行为！可见，上述代码确实是有Bug的。
有Bug没关系，可问题的关键是，到底是哪行语句引入的坑呢？（如果不看本文后续解释，大家可以快速定位到问题根源么）

没错，就是b_dict[sk] = sv这句（第15行），它的实际行为是将b_dict[sk]绑定到sv这个结构上，而sv是与a_dict关联的，所以对b_dict[sk]做的append操作相当于通过"引用"直接操作a_dict的内容！这种行为是符合Python Naming Rule的，只是不符合我们的预期。。。

上面的代码还说明，dict的kesy()/values()/items()方法返回的list与dict本身存在绑定关系（即不是通过“深拷贝”生成list），修改返回的list时，dict原来的内容也会被更新。
可以用更简化的例子来验证这个结论：

>>> a = {'k1' : ['v1'], 'k2' : ['v2']}
>>> a.items()
[('k2', ['v2']), ('k1', ['v1'])]  ## 初始时，a.items()的内容
>>> id(a.items())  
140251308636208
>>> x = a.items()
>>> id(x)
140251308636352  ## 由于items()每次返回一个新list，所以id(x)与id(a.items())值不一致是可以理解的，如果值一样也只是巧合
>>> x
[('k2', ['v2']), ('k1', ['v1'])]  
>>> id(x[0][1])  
140251308636136
>>> id(a.items()[0][1])
140251308636136
>>> id(a['k2'])
140251308636136  ## 特别注意，a['k2']与x[0][1]的id值是一样的，说明它们指向相同的内存地址
>>> x[0][1].append('test')
>>> a
{'k2': ['v2', 'test'], 'k1': ['v1']}  ## 通过x修改内容后，a的内容也被修改了！

从上面两端代码实例的分析可看到， Bug的根源是：赋值操作是绑定变量名与实际对象的过程，而非重新创建并初始化对象的过程。
认识到这一点后，Bug的修复就很简单了。下面是无bug的代码片段：

#!/bin/env python
#-*- encoding: utf-8 -*-

def test():
    a_dict = {'a1' : {'s1' : ['foo']}, 'a2' : {'s1' : ['bar']}}
    b_dict = {}
    print 'begin: a_dict=%s' % (a_dict)
    print 'begin: b_dict=%s' % (b_dict)
    for k in a_dict.keys():
        for sk, sv in a_dict[k].items():
            if sk in b_dict:
                b_dict[sk].append(sv)
                b_dict[sk].append('addition')
            else:
                b_dict[sk] = list(sv)  ## 注意这里通过list()重新创建对象实现了“深拷贝”的效果
    print 'end: a_dict=%s' % (a_dict)
    print 'end: b_dict=%s' % (b_dict)

    return 0

if '__main__' == __name__:
    test()

上面的代码只修改了一处地方（具体见注释），就可以得到符合预期的结果：

begin: a_dict={'a1': {'s1': ['foo']}, 'a2': {'s1': ['bar']}}
begin: b_dict={}
end: a_dict={'a1': {'s1': ['foo']}, 'a2': {'s1': ['bar']}}
end: b_dict={'s1': ['foo', ['bar'], 'addition']}

【参考资料】
PythonDoc: Naming and binding

==================== EOF ====================