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_<platform>.c文件中定义.在基于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"作为可能的后缀:

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. 1994年的python.org/cpython-fullhistory/diff/2230/Python/import.c ，其中添加了新的模块命名方案(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屋！