Python共享对象模块命名约定 [英] Python shared object module naming convention
问题描述
我用 C++ 编写了一个 Python 模块，并将其构建为共享对象库，并且运行良好.但是在弄清楚所有这些的同时，我注意到(通过 strace)Python 会寻找一些不同的变体 import 被调用.特别是，当我说 import foo 时，Python 会按顺序搜索:
I have written a Python module in C++ and built it as a shared object library and it worked fine. But while figuring all that out, I noticed (via strace) that Python looks for a few different variations import is called. In particular, when I say import foo, Python searches for, in order:
- foo(一个目录)
- foo.so
- foomodule.so
- foo.py
- foo.pyc
除了 foomodule.so 之外，这一切都很好理解.为什么 Python 会同时查找 name.so 和 namemodule.so 中的所有内容?是不是什么历史文物?我搜索了很多，并没有给出任何解释，我想知道我是否应该将我的模块命名为 foomodule.so 而不是 foo.so.我的系统似乎有一些遵循每个约定的现有 Python 模块，所以我不禁想知道不同的名称是否暗示了什么.
This was all pretty understandable except for foomodule.so. Why does Python look for everything both as name.so and namemodule.so? Is it some historical artifact? I searched quite a bit and came up with no explanation at all, and am left wondering if I should name my module foomodule.so instead of foo.so. My system seems to have some existing Python modules following each convention, so I can't help but wonder if the different names imply something.
推荐答案
这实际上是平台相关的，Python 有不同的后缀，它会根据操作系统尝试.下面是import.c中后缀表的初始化:
This is actually platform-dependent, Python has different suffixes that it tries depending on the operating system. Here is the initialization of the suffix table in import.c:
#ifdef HAVE_DYNAMIC_LOADING
memcpy(filetab, _PyImport_DynLoadFiletab,
countD * sizeof(struct filedescr));
#endif
memcpy(filetab + countD, _PyImport_StandardFiletab,
countS * sizeof(struct filedescr));
filetab[countD + countS].suffix = NULL;
_PyImport_Filetab = filetab;
所以它加入了两个列表，_PyImport_DynLoadFiletab 和 _PyImport_StandardFiletab.后者更简单，它在同一文件中定义为 [".py", ".pyw", ".pyc"] (第二个条目仅在 Windows 上存在)._PyImport_DynLoadFiletab 在各种 dynload_ 文件中定义.在基于 Unix 的系统上，它的值为 [".so", "module.so"]，对于 CygWin，它定义了 [".dll", "module.dll"]> 而对于 OS/2，它是 [".pyd", ".dll"] 而对于 Windows，它只是 [".pyd"].
So it joins two lists, _PyImport_DynLoadFiletab and _PyImport_StandardFiletab. The latter is the easier one, it is defined as [".py", ".pyw", ".pyc"] in the same file (second entry is only present on Windows). _PyImport_DynLoadFiletab is defined in various dynload_<platform>.c files. On Unix-based systems its value is [".so", "module.so"], for CygWin it defines [".dll", "module.dll"] whereas for OS/2 it is [".pyd", ".dll"] and for Windows it is simply [".pyd"].
我查阅了源代码的历史，最终发现了 1999 年的这一变化，显然添加了module.so"作为可能的后缀:http://hg.python.org/cpython-fullhistory/diff/8efa37a770c6/Python/importdl.c.因此，这些更改最初是为 NeXTStep(最终成为 Mac OS X 的那个)添加的，仅用于特定的链接设置.我不知道这个操作系统，所以很难说为什么这样做 - 我怀疑这只是为了防止命名冲突.例如.框架库 foo.so 可能已经加载，操作系统不允许加载另一个同名的库.所以 foomodule.so 是一种妥协，允许名为 foo 的 Python 模块仍然存在.
I went through the source code history and finally arrived at this change from 1999 that apparently added "module.so" as a possible suffix: http://hg.python.org/cpython-fullhistory/diff/8efa37a770c6/Python/importdl.c. So the changes were originally added for NeXTStep (the one that eventually became Mac OS X), for particular linking settings only. I don't know this OS so it is hard to tell why it was done - I suspect that it was simply to prevent naming conflicts. E.g. a framework library foo.so might be loaded already and the OS won't allow loading another library with the same name. So foomodule.so was a compromise to allow a Python module with the name foo to exist nevertheless.
编辑:上面的段落是错误的 - 我没有回溯到足够远的历史，感谢 senderle 指出这一点.事实上，有趣的变化似乎是 http://hg.python.org/cpython-fullhistory/diff/2230/Python/import.c 从 1994 年开始添加新的模块命名方案 (foo.so) 作为替代旧方案 (foomodule.so).我猜想旧形式在某个时候已被弃用，因为在对该代码的众多重写之一中，对某些平台(如 Windows)的支持已被删除.请注意，即使在首次引入时，短模块名称版本也首先列出 - 这意味着它已经是首选变体.
Edit: The paragraph above was wrong - I didn't go far enough back in history, thanks to senderle for pointing that out. In fact, the interesting change appears to be http://hg.python.org/cpython-fullhistory/diff/2230/Python/import.c from 1994 which is where a new module naming scheme (foo.so) was added as an alternative to the old scheme (foomodule.so). I guess that the old form became deprecated at some point given that support for it has been removed for some platforms like Windows in one of the numerous rewrites of that code. Note that even when it was first introduced the short module name version was listed first - meaning that it already was the preferred variant.
Edit2:我搜索了 1994 年的邮件列表/新闻组，看看是否在某处讨论过此更改 - 看起来不像，Guido van Rossum 似乎在没有告诉任何人的情况下实施了它.
Edit2: I searched the mailing list/newsgroup from 1994 to see whether this change was discussed somewhere - it doesn't look like it was, Guido van Rossum seems to have implemented it without telling anyone.
这篇关于Python共享对象模块命名约定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
