在Python中，类名的自动完全限定如何工作？ [与对象酸洗有关]

Question

（可以直接跳到问题，进一步向下，并跳过介绍。）

从用户定义的类中挑选Python对象存在一个常见的困难：

# This is program dumper.py
import pickle

class C(object):
    pass

with open('obj.pickle', 'wb') as f:
    pickle.dump(C(), f)

实际上，试图从另一个程序loader.py获取对象

# This is program loader.py
with open('obj.pickle', 'rb') as f:
    obj = pickle.load(f)

结果是

AttributeError: 'module' object has no attribute 'C'

实际上，该类是通过名称（“C”）进行loader.py ，而loader.py程序对C没有任何了解。 常见的解决方案包括导入

from dumper import C  # Objects of class C can be imported

with open('obj.pickle', 'rb') as f:
    obj = pickle.load(f)

但是，这个解决方案有一些缺点，包括必须导入pickle对象引用的所有类（可能有很多）; 此外，本地命名空间被dumper.py程序中的名称污染。

现在，解决这个问题的方法包括在酸洗之前完全限定对象：

# New dumper.py program:
import pickle
import dumper  # This is this very program!

class C(object):
    pass

with open('obj.pickle', 'wb') as f:
    pickle.dump(dumper.C(), f)  # Fully qualified class

取消上面原始的loader.py程序现在直接工作（无需from dumper import C ）。

问题 ：现在， dumper.py其他类似乎在酸洗时自动完全合格，我很想知道它是如何工作的，以及这是否是一个可靠的，记录在案的行为：

import pickle
import dumper  # This is this very program!

class D(object):  # New class!
    pass

class C(object):
    def __init__(self):
        self.d = D()  # *NOT* fully qualified

with open('obj.pickle', 'wb') as f:
    pickle.dump(dumper.C(), f)  # Fully qualified pickle class

现在，使用原始的loader.py程序进行unpickling也可以工作（无需from dumper import C loader.py from dumper import C ）; print obj.d给出了一个完全限定的类，我觉得很惊讶：

<dumper.D object at 0x122e130>

这种行为非常方便，因为只有顶层的pickle对象必须使用模块名称（ dumper.C() ）完全限定。 但这种行为是否可靠且有记录？ 为什么这些类被名称（“D”）腌制，但是unpickling决定pickle self.d属性是类dumper.D （而不是一些本地D类）？

PS：问题，精炼 ：我刚刚注意到一些有趣的细节可能指向这个问题的答案：

在dumper.py程序dumper.py ，使用第一个dumper.py程序（没有import dumper程序的程序） print self.d <__main__.D object at 0x2af450>打印<__main__.D object at 0x2af450> 。 在另一方面，做import dumper和创建与所述对象dumper.C()在dumper.py使得print self.d打印<dumper.D object at 0x2af450> ：所述self.d属性被Python自动合格！ 因此，似乎pickle模块在上面描述的良好的unpickling行为中没有任何作用。

因此问题是：为什么Python将D()转换为完全限定的dumper.D ，在第二种情况下？ 这是在某处记录的吗？

Answer 1

当您的类在主模块中定义时，pickle希望在它们被打开时找到它们。 在第一种情况下，类是在主模块中定义的，因此当加载器运行时， loader是主模块而pickle无法找到类。 如果你看一下obj.pickle的内容，你会看到名称__main__导出为你的C和D类的命名空间。

在第二种情况下，dumper.py会自行导入。 现在你实际上定义了两组独立的C和D类：一组在__main__命名空间中，一组在dumper命名空间中。 您序列化dumper命名空间中的obj.pickle （查看obj.pickle以进行验证）。

pickle将尝试动态导入命名空间（如果找不到），因此当loader.py运行pickle时，会导入dumper.py以及dumper.C和dumper.D类。

由于您有两个单独的脚本dumper.py和loader.py，因此只定义它们在公共导入模块中共享的类是有意义的：

common.py

class D(object):
    pass

class C(object):
    def __init__(self):
        self.d = D()

loader.py

import pickle

with open('obj.pickle','rb') as f:
    obj = pickle.load(f)

print obj

dumper.py

import pickle
from common import C

with open('obj.pickle','wb') as f:
    pickle.dump(C(),f)

请注意，即使dumper.py在这种情况下转储C() ，pickle也知道它是一个common.C对象（参见obj.pickle ）。 当loader.py运行时，它将动态导入common.py并成功加载该对象。

Answer 2

这是发生了什么：在导入时dumper （或做from dumper import C从内） dumper.py ， 整个程序再次解析 （这可以通过插入模块在打印中可以看出）。 此行为是预期的，因为dumper不是已加载的模块（但__main__被视为已加载） - 它不在sys.modules 。

如在Mark的答案所示，自然导入模块资格的模块中定义的所有的名称，以便self.d = D()被解析为类的dumper.D时重新评估文件dumper.py （这等效于解析common.py ，在Mark的回答中）。

因此，解释了import dumper （或from dumper import C ）技巧，并且酸洗不仅完全符合C类，而且符合D类。 这使得外部程序的拆卸更容易！

这也表明在dumper.py完成的import dumper dumper.py强制Python解释器解析程序两次，这既不高效也不优雅。 因此，程序中的酸洗类和在另一个程序中取消它们可能最好通过Mark的答案中概述的方法来完成：腌制类应该在一个单独的模块中。