【问题标题】:Are unused imports acceptable if they run a function on import?如果在导入时运行函数,未使用的导入是否可以接受?
【发布时间】:2018-04-20 12:36:08
【问题描述】:

我使用许多不同的基本脚本在不同时间推送数据、提取报告等。这些脚本有一个可在 VM 上运行的 cron 条目。

当每个脚本启动时,我想运行一个共享的函数。但是,我目前的执行方式还不清楚。

一个基本的例子,我有:

sharedmodule.py:

def script_start_func()
    # do stuff

script_start_func()

然后我将此模块导入到每个正在运行的脚本中,以便在导入模块时运行该函数,如下所示:

one_of_many_different_scripts.py:

import sharedmodule  #flagged in IDE as unused

# do normal script stuff

感觉应该有更好的方法来达到同样的目的,尽管在当时这似乎是一种合理的方法,不需要在每个脚本的顶部加上sharedmodule.script_start_func()

有没有首选的操作方式?

我开始认为实际调用该函数只是多出一行,并且很清楚发生了什么?

我已经搜索过这个主题,但似乎找不到现有答案。

谢谢

【问题讨论】:

  • 然后让其他东西运行该脚本,不要强迫您的代码必须调用它。
  • “当每个脚本启动时,我想运行一个函数” 然后在脚本启动时调用该函数看起来是正确的做法。你在担心什么?

标签: python import


【解决方案1】:

我将通过引用“Python之禅”来回答:

> python -c "import this"

Python 之禅,作者 Tim Peters

美丽胜于丑陋。
显式优于隐式。
简单胜于复杂。
复杂胜于复杂。
平面比嵌套好。
稀疏优于密集。
可读性很重要。
特殊情况不足以打破规则。
虽然实用胜过纯粹。
错误绝不应无声无息地过去。
除非明确静音。
面对模棱两可,拒绝猜测的诱惑。
应该有一种——最好只有一种——明显的方法。
虽然这种方式一开始可能并不明显,除非你是荷兰人。
现在总比没有好。
虽然现在从来没有比现在更好正确
如果实现难以解释,那就是个坏主意。
如果实现很容易解释,那可能是个好主意。
命名空间是一个很棒的想法——让我们做更多的事情!

第二行指出显式优于隐式。这就是我想要传达的。显式调用函数比隐式调用要好得多,原因如下:

  • 它让您可以控制调用该函数的时间和地点
  • 它有助于在出现问题时进行调试,因为您可以注释掉调用,在调用之前和/或之后打印一些调试信息
  • 代码更容易理解,因为该调用并未隐藏在您的调用脚本中

这样做的成本当然是必须多输入一行,但我相信收益大于成本。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-06-20
    • 1970-01-01
    • 2023-03-28
    • 1970-01-01
    • 1970-01-01
    • 2019-07-12
    相关资源
    最近更新 更多