关于python：当存在同名模块时从内置库导入

Importing from builtin library when module with same name exists

情况：-我的项目文件夹中有一个名为"日历"的模块-我想使用Python库中的内置日历类-当我使用"从日历导入日历"时，它会抱怨，因为它正试图从我的模块中加载。

我做了一些搜索，似乎找不到解决问题的方法。

当存在同名的本地模块时，如何访问Python中的标准库模块？
http://docs.python.org/whatsnew/2.5.html
在python中导入模块时，如何避免一直写模块名？

有没有不必重新命名模块的想法？

不需要更改模块的名称。相反，您可以使用绝对导入来更改导入行为。例如，对于stem/socket.py i，导入socket模块如下：

1 2	from __future__ import absolute_import import socket

。

这只适用于Python2.5及更高版本；它是启用行为，这是Python3.0及更高版本中的默认行为。皮林特会抱怨代码，但它是完全有效的。

相关讨论

实际上，解决这个问题相当容易，但是实现总是有点脆弱，因为它依赖于Python导入机制的内部，并且在未来的版本中它们可能会发生变化。

(以下代码显示了如何加载本地和非本地模块以及它们如何共存)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

def import_non_local(name, custom_name=None):
import imp, sys

custom_name = custom_name or name

f, pathname, desc = imp.find_module(name, sys.path[1:])
module = imp.load_module(custom_name, f, pathname, desc)
f.close()

return module

# Import non-local module, use a custom name to differentiate it from local
# This name is only used internally for identifying the module. We decide
# the name in the local scope by assigning it to the variable calendar.
calendar = import_non_local('calendar','std_calendar')

# import local module normally, as calendar_local
import calendar as calendar_local

print calendar.Calendar
print calendar_local

如果可能，最好的解决方案是避免使用与标准库或内置模块名称相同的名称命名模块。

相关讨论

解决这个问题的唯一方法就是自己劫持进口机器。这不容易，而且充满危险。你应该不惜一切代价避免这个颗粒状的灯塔，因为危险太危险了。

改为重命名模块。

如果你想学习如何劫持内部进口机器，下面是你将要了解如何做到这一点的地方：

python 2.7文档的导入模块部分
python 3.2文档的导入模块部分
PEP 302-新进口挂钩

有时有充分的理由去冒这个险。你给出的理由不在其中。重命名模块。

如果您走的是危险的道路，那么您将遇到的一个问题是，当您加载一个模块时，它以一个"正式名称"结束，这样Python就可以避免再次解析该模块的内容。模块的"正式名称"到模块对象本身的映射可以在sys.modules中找到。

这意味着，如果您在一个地方使用import calendar，则导入的任何模块都将被视为正式名称为calendar的模块，以及在其他任何地方使用import calendar的所有其他尝试(包括在属于主python库的其他代码中)，都将获得该日历。

可以使用python 2.x中的imputil模块来设计一个客户导入器，该模块导致从某些路径加载的模块首先查找它们导入的模块，而不是sys.modules或类似的模块。但这是一个非常棘手的事情，而且它在Python3.x中也不会工作。

你可以做一件极其丑陋和可怕的事情，但这并不涉及钩住进口机制。这可能是你不应该做的，但它可能会起作用。它将您的calendar模块转换为系统日历模块和日历模块的混合体。感谢BoazYaniv为我使用的功能提供了框架。把这个放在你的calendar.py文件的开头：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

import sys

def copy_in_standard_module_symbols(name, local_module):
import imp

for i in range(0, 100):
random_name = 'random_name_%d' % (i,)
if random_name not in sys.modules:
break
else:
random_name = None
if random_name is None:
raise RuntimeError("Couldn't manufacture an unused module name.")
f, pathname, desc = imp.find_module(name, sys.path[1:])
module = imp.load_module(random_name, f, pathname, desc)
f.close()
del sys.modules[random_name]
for key in module.__dict__:
if not hasattr(local_module, key):
setattr(local_module, key, getattr(module, key))

copy_in_standard_module_symbols('calendar', sys.modules[copy_in_standard_module_symbols.__module__])

相关讨论

不纯被认为是不赞成的。您应该使用IMP模块。
顺便说一下，它与Python3完全兼容。而且根本不用那么多毛。但您应该始终注意，依赖于Python的代码以某种方式处理路径或按这种顺序查找模块，可能早晚会中断。
@博阿兹·亚尼夫：我知道，但在python 3之前，似乎没有一个功能的替代品。据我所知，imp模块只提供了标准导入机制的实现，而不是一种全局连接导入机制以使其按您的需要执行的方法。
是的，但在这种孤立的情况下(模块名冲突)，挂接导入机制是一种过度杀伤力。因为它毛茸茸的，不相容，所以最好别管它。
@博阿兹·亚尼夫：但是为了让import calendar在每一个情况下都能做到你所期望的，钩住进口机制是唯一的办法。不过，在这个特定的案例中，我可以想到一个非常丑陋的方法来处理这个问题。我来概述一下。但这是邪恶的。它确实运用了你的想法。
@波阿斯·亚尼夫：好了，我的回答包括了你不应该使用的邪恶、可怕、丑陋的机制。
啊，我明白了。是的，这是一个相当大的黑客。：)但是，除了随机名称和与sys.modules混淆之外，我还担心如何有效地合并本地和标准模块的名称空间。
@博阿斯·亚尼夫：这很令人担忧。如果系统日历模块中的函数在模块全局名称空间中添加了更多的名称，那么如果模块外部的代码希望能够看到这些名称，则可能会出现问题。
感谢您如此详细的回复！既然我知道了其中的原因，我绝对不会再冒这个险了。我希望有一个简单的方法来解决这个问题，因为"日历"是一个很常见的名字。
+1:合并名称空间既聪明又危险。简言之，我喜欢它：)
而且，不管是不是丑陋的黑客，它都能很好地工作。不管你信不信由你，我很快就会在生产代码中使用这个技巧！我有一个项目，它的源代码包是code，我现在不愿意把所有东西都重命名为src，因为pydev导入stdlib'd code.InteractiveConsole。
@梅斯特里翁：嗯，我不确定我是高兴还是害怕。；-)
看一看，自己决定：github.com/mestrelion/singularity/blob/master/code/uuu init_uuuuzwnj；&8203；py
@无所不知：事实上，我必须删除del声明才能使它真正起作用。尽管setattr到local_module，类仍然绑定到random_name模块。功能和其他变量工作得很好。你知道为什么吗？
你怎么知道类仍然绑定到random_name模块？
@无所不知，现在我有足够的代表点，我可以评论和问这个：)为什么这是一个"丑陋和可怕"的解决方案？我想用它来组合套接字函数，以便在日志记录中进行插入。这种合并可以在安装后一次完成。我对此提出了一个问题，其中一个建议是使用猴希杰克。这也是丑陋和可怕的吗？它只用于记录消息有帮助吗？
@Mestrelion您在生产中对这个解决方案有什么问题吗？
@jspacek没有，到目前为止还不错，但是只有在使用pydev的debbuger时才会发生冲突，而不是经常使用。确保您检查了最新的代码(Github中的URL)，因为它与上面的答案有点不同。
@中心术是碰撞问题的主要考虑因素吗？我已经收到一些建议，说合并也会影响向后兼容性，尽管这听起来不像是您的问题。
@JSPACEK：这是一个游戏，而不是一个库，所以在我的例子中，向后兼容性根本就不是问题。并且只有在通过pydev-ide(使用python的codestd模块)运行时才会发生名称空间冲突，这意味着只有一小部分开发人员可能会对这种"合并黑客"有任何问题。用户不会受到任何影响。
@感谢花时间澄清上下文，真的很感激。我将探讨补丁，这是为了帮助解决兼容性问题，因为在我们的案例中，用户和开发者可能会受到影响。
@jspacek——这是一个丑陋的黑客，因为它基本上是用来自某个系统模块的大量名称来修补模块。猴子以一种非常有针对性的方式修补是一种非常令人怀疑的做法，并且以这种方式集体修补看起来相当令人不安。

我想提供我的版本，它结合了博阿兹·亚尼夫和无所不能的解决方案。它将导入模块的系统版本，与以前的答案有两个主要区别：

支持"dot"符号，例如package.module
是对系统模块的import语句的替换，这意味着您只需替换这一行，如果已经对模块进行了调用，则它们将按原样工作。

把这个放在一个可以访问的地方，这样你就可以调用它(我的在我的文件中有我的)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

class SysModule(object):
pass

def import_non_local(name, local_module=None, path=None, full_name=None, accessor=SysModule()):
import imp, sys, os

path = path or sys.path[1:]
if isinstance(path, basestring):
path = [path]

if '.' in name:
package_name = name.split('.')[0]
f, pathname, desc = imp.find_module(package_name, path)
if pathname not in __path__:
__path__.insert(0, pathname)
imp.load_module(package_name, f, pathname, desc)
v = import_non_local('.'.join(name.split('.')[1:]), None, pathname, name, SysModule())
setattr(accessor, package_name, v)
if local_module:
for key in accessor.__dict__.keys():
setattr(local_module, key, getattr(accessor, key))
return accessor
try:
f, pathname, desc = imp.find_module(name, path)
if pathname not in __path__:
__path__.insert(0, pathname)
module = imp.load_module(name, f, pathname, desc)
setattr(accessor, name, module)
if local_module:
for key in accessor.__dict__.keys():
setattr(local_module, key, getattr(accessor, key))
return module
return accessor
finally:
try:
if f:
f.close()
except:
pass

例子

我想导入mysql.connection，但我有一个本地包，已经叫做mysql(官方mysql实用程序)。为了从System MySQL包中获取连接器，我替换了这个：

1	import mysql.connector

。

有了这个：

1
2
3

import sys
from mysql.utilities import import_non_local # where I put the above function (mysql/utilities/__init__.py)
import_non_local('mysql.connector', sys.modules[__name__])

。结果

1 2	# This unmodified line further down in the file now works just fine because mysql.connector has actually become part of the namespace self.db_conn = mysql.connector.connect(**parameters)

更改导入路径：

1
2
3
4
5

import sys
save_path = sys.path[:]
sys.path.remove('')
import calendar
sys.path = save_path

号

相关讨论