Python Utils 文件夹放在哪里?

发布于 2024-10-20 13:41:36 字数 386 浏览 6 评论 0原文

我有一大堆像这样组织的脚本:

root
  group1
    script1.py
    script2.py
  group2
    script1.py
    script2.py
  group3
    script1.py
    script2.py
  utils
    utils1.py
    utils2.py

所有脚本*.py都使用utils文件夹内的函数。目前,我将 utils 路径附加到脚本中以便导入 utils。

然而,这似乎是不好的做法(或“不是Pythonic”)。此外,实际上的组并不像这样平坦,并且 util 文件夹比上面列出的要多。因此,附加路径解决方案变得越来越混乱。

我怎样才能以不同的方式组织这个?

I've a whole bunch of scripts organized like this:

root
  group1
    script1.py
    script2.py
  group2
    script1.py
    script2.py
  group3
    script1.py
    script2.py
  utils
    utils1.py
    utils2.py

All the scripts*.py use functions inside the utils folder. At the moment, I append the utils path to the scripts in order to import utils.

However, this seems to be bad practice (or "not Pythonic"). In addition, the groups in actuality is not as flat as this and there are more util folders than listed above. Hence, the append path solution is getting messier and messier.

How can I organize this differently?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

征棹 2024-10-27 13:41:37

您可能还感兴趣:
Python 3:安装的好位置自己的和第 3 方的软件包?

是的,我可以看到软件包是如何提供帮助的,但是如果您仍在使用 utils 并在处理 group1、group2 等时更改它们,那么进行安装会产生很大的开销。

仍在寻找对此的良好答案。

You might also be interested in:
Python 3: Good location(s) to install own and 3rd party packages?

Yes, I can see how packages are a help, but making an install is a lot of overhead if you are still working on the utils and changing them as you work on group1, group2 etc.

Still looking for good answer to this.

猫腻 2024-10-27 13:41:37

我们无法从人为的示例中真正了解您的用例是什么。我建议制作一个包含 utils 模块和其他脚本的包,然后使用脚本中的相对导入,例如 from ..utils import utils1。当然,您不会将顶级包称为“root”,而是选择一个类似于您的项目名称的名称。

如果您确实有很多这样的脚本,那么使用一个运行脚本可能是有意义的,然后根据命令行参数导入模块。像 runner.py 这样的东西会导入并执行 .commands.somecommand.runFunction (Django 就是这样做的,例如 - 使项目可扩展)。

We can't really know what your use case is from the contrived example. I would recommend to make a package containing your utils module and the other scripts, and then using relative imports from the scripts, such as from ..utils import utils1. Of course you wouldn't call the top package "root" but choose a name like your project name.

If you really have a lot of those scripts, it might make sense to have a single run script which then imports modules according to the cmdline parameters. Something like runner.py <somecommand> would then import and execute <top package>.commands.somecommand.runFunction (Django does this, for example - makes the project extensible).

拥抱我好吗 2024-10-27 13:41:36

首先使所有目录可导入,即使用__init__.py
然后有一个顶级脚本,它接受参数并基于该参数调用脚本。

从长远来看,Keith 提到的关于 distutils 的内容是正确的。否则,这是一个更简单的(当然不是最好的)解决方案。

组织

runscript.py
group1
    __init__.py
    script1.py
utils
    __init__.py
    utils1.py

调用

python runscript -g grp1 -s script1

runscript.py

import utils

def main():
    script_to_exec = process_args()
    import script_to_exec as script # __import__
    script.main()

main()

也许你的脚本可以有 main 函数,然后由 runscript 调用。
我建议您在顶层有一个导入脚本的脚本。

Make all your directories importable first i.e. use __init__.py.
Then have a top level script that accepts arguments and invokes scripts based on that.

For long term what Keith has mentioned about distutils holds true. Otherwise here is a simpler (sure not the best) solution.

Organization

runscript.py
group1
    __init__.py
    script1.py
utils
    __init__.py
    utils1.py

Invocation

python runscript -g grp1 -s script1

runscript.py

import utils

def main():
    script_to_exec = process_args()
    import script_to_exec as script # __import__
    script.main()

main()

Maybe your script can have main function which is then invoked by runscript.
I suggest that you have a script at the top level which imports the script.

遮云壑 2024-10-27 13:41:36

你需要使用包。当目录中包含名为 __init__.py 的文件时,Python 会将其识别为包。最好还是使用 distutils 制作一个源包,该包也将安装它你。几乎不应该修改 sys.path,安装包会将其放置在标准位置(站点包),因此您不必修改它。

You need to use packages. Python recognizes a directory as a package when it has a file named __init__.py in it. Better still use distutils to make a source package which will also install it for you. Modifying sys.path should almost never be done, and installing packages will place it in a standard place (site-packages) so you don't have to modify it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文