28

I'm writing a family of Python scripts within a project; each script is within a subdirectory of the project, like so:

projectroot
  |
  |- subproject1
  |    |
  |    |- script1.main.py
  |    `- script1.merger.py
  |
  |- subproject2
  |    |
  |    |- script2.main.py
  |    |- script2.matcher.py
  |    `- script2.merger.py
  |
  `- subproject3
       |
       |- script3.main.py
       |- script3.converter.py
       |- script3.matcher.py
       `- script3.merger.py

Now several of the scripts share some code. The shared code is best considered part of the project itself, and not something I would compile separately and make a library out of, or drop in a sitewide PYTHONPATH. I could place that code in various places, such as in the projectroot directory itself, or in a child directory of projectroot called common (perhaps).

However, most of the ways I have thought of so far involve making packages out of my subprojects with empty __init__.py files and using relative imports (or redundantly messing with sys.path in every subproject. Worse, it seems like building a package structure around this family of scripts runs afoul of the following warning from the rejected PEP-3122:

Attention! This PEP has been rejected. Guido views running scripts within a package as an anti-pattern.

If scripts within a package is anti-patternish, how can I set things up in a way which keeps the common code in the same project? Or is a module and package-based system acceptable here? Which is the cleanest approach? (FWIW I would prefer to have a file such as shared.py or common.py in the project root directory, rather than making a utility directory that is a sibling to the "real" subprojects.)

4

3 回答 3

29

我建议将琐碎的“启动器”脚本放在项目的顶层，并将每个子项目文件夹放入包中。包中的模块可以相互导入，也可以将公共代码分解到一个common包中。

如果我们假设各种merger模块可以重构为共享版本，则结构如下所示：

projectroot
  |- script1.py # launcher scripts, see below for example code
  |- script2.py
  |- script3.py
  |
  |- common
  |    |- __init__.py
  |    |- merger.py # from other packages, use from ..common import merger to get this
  |
  |- subproject1
  |    |- __init__.py # this can be empty
  |    |- script1_main.py
  |
  |- subproject2
  |    |- __init__.py
  |    |- script2_main.py
  |    |- script2_matcher.py
  |
  |- subproject3
       |- __init__.py
       |- script3_main.py
       |- script3_converter.py
       |- script3_matcher.py

启动器脚本可以非常简单：

from subproject1 import script1_main

if __name__ == "__main__":
    script1_main.main()

也就是说，它所做的只是导入适当的“scriptN_main”模块并在其中运行一个函数。使用简单的脚本也可能对脚本启动速度有一些小的好处，因为main模块可以将其编译后的字节码缓存到.pyc文件中，而脚本永远不会被缓存。

注意：我重命名了您的模块，将字符换成_了.字符。.标识符（例如模块名称）中不能有 a ，因为 Python 期望它指示属性访问。这意味着这些模块永远无法导入。（我猜这只是示例文件的工件，而不是您在真实代码中拥有的东西。）

于 2013-08-13T06:05:05.557 回答
1

我的偏好是一个单独的“bin”或“scripts”目录，子项目作为库/包：

projectroot
  |
  |- scripts
  |
  |- lib
  |    |
  |    `- matcher.py
  |    `- merger.py
  |    `- subproject1
  |    `- subproject2
  |    `- subproject3

您的脚本的想法可以像通常的包一样引用任何必要的子项目。您的子项目也可以通过导入相互引用。

然后，如果有帮助，您还可以拥有一个为您设置子项目包的主脚本或共享脚本。

于 2013-08-06T18:04:10.007 回答
0

我最近发现了这种技术，它似乎适用于 Python 3.9。这与 Blckknght 的答案并没有太大区别，但它避免了为每个子项目projectroot本身运行脚本的需要。

projectroot
  |
  |- common
  |    |
  |    `- merger.py
  |
  |- subproject1
  |    |
  |    `- __main__.py
  |
  |- subproject2
  |    |
  |    |- __main__.py
  |    `- matcher.py

从projectroot目录中，运行

python -m subproject1

python -m subproject2

实际上，您将subproject1和subproject2视为“应用程序包”。

subproject1 和 subproject2 似乎都可以import common.merger直接使用，而无需任何特殊措施，例如破解导入路径。

有一个小故障，可能重要也可能不重要。在每个子项目中，导入根目录是这样的projectroot，因此您必须在项目本身中使用绝对导入或显式相对导入。

import .matcher

或者

import subproject2.matcher

但不是

import matcher # ModuleNotFoundError: No module named 'matcher'

另一个缺点是它可能需要一个不明显的-m标志来运行应用程序。

于 2021-07-01T09:18:58.900 回答