我正在研究一个Python web应用程序，其中有一些小模块可用于非常特定的功能：session.py,logger.py,database.py等等。而“小”我确实意味着小;这些文件中的每一个目前都包含大约3-5行代码，或者最多可以包含10行代码。我可能会有几个导入和一个类定义或两个。我想知道，是否有任何理由我应该或不应该将它们合并到一个模块中，比如misc.py？Python：更喜欢几个小模块还是更大的模块？
我的想法是，有单独的模块，代码清晰帮助，后来，如果由于某些原因，这些模块增长到超过10行，我就不会觉得那么不好让他们分开。但另一方面，看起来像是浪费了一大堆只有几行文件的文件！多文件和单文件方法在资源使用方面是否存在显着差异？ （当然，我无处在那里我应该担心资源使用点附近，但我忍不住问...）
我检查四周，看看这是否以前已经问过，并没有看到任何特定于Python的东西，但如果它实际上是重复的，我会很高兴被指向正确的方向。
我的想法是，有独立的 模块，代码的清晰度上有所帮助，并 后，如果由于某些原因，这些 模块增长到超过10行，我 就不会觉得那么不好让他们 分离。
这个。保持它的方式。
+1模块是重用的单位。如果您可以考虑重复使用它，请将它分开。 – 2009-08-02 22:07:19
导入模块会导致文件查找/读取操作，这非常昂贵。所以有一个不重要的应用程序启动成本，有模块。除非以压缩模式分发您的代码，否则拥有几百个模块将花费大约2-5秒的时间导入。 （如果从网络导入则更多）。 – Kozyarchuk 2009-08-03 03:14:47
“具有模块的非平凡应用程序启动成本”？真？我从未注意到。你有任何测量？你能否展示这种“不平凡”的成本？我们有一台运行数天的网络服务器。你是说，与100小时的运行时间相比，进口是可衡量的吗？ – 2009-08-03 12:17:29
我个人觉得更容易保持这样的事情在一个文件中，只为编辑在我的编辑的文件数量较少的实用性。
要做的重要事情是将视为不同的代码段，就好像它们在不同的文件中一样，所以您确保以后可以轻松地将它们分开，因为您引用的原因。因此，例如，不要在不同的部分之间引入依赖关系，这将导致以后难以解决这些问题。
当然，你可以有任意多的模块，只要你喜欢。
但现在让尽可能想一点，当我们把每一小段代码到一个单一的文件会发生什么。
我们最终将在数百import语句在任何没有价值的模块。当然，你也可以通过在分离的文件中明确显示来节省一点。但猜猜怎么样：没人能记住这么多模块名称，并且最终可能最终搜索正确的文件......
我尝试将属于一个的东西放在一个文件中（除非它变得很大！） 。但是当我的系统中有不属于其他组件的小函数或类时，我有“util”模块或类似的东西。我也尝试按照我的应用程序分层对这些进行分组，或者通过其他方式将它们分开。一个单独的标准可能是：用于UI的实用程序和那些没有的实用程序。
随着模块的用户，我非常喜欢时，我可以包括经由单个导入整个模块。除非有理由允许导入不同的备选项，否则不要让包的用户进行多次导入。
顺便说一句，我们没有理由在单个模块不能由多个源文件。最简单的情况是使用__init__.py文件简单地将所有其他代码加载到模块的名称空间中。
小。
对于命令行脚本，有最有可能不会有太大的区别，除非每次调用调用模块中的所有文件，在这种情况下会有轻微的性能代价为n个文件需要打开VS之一。
对于mod_python的存在极有可能会是没有区别的字节编译的模块为Apache过程的持续时间活路。
谷歌应用程序引擎，虽然会有一个性能命中，除非该服务正在不断使用，并且是“热”，因为每个冷启动需要打开所有文件。
我还想补充一点，有许多独立的模块，（数据/执行）隐藏/封装/帮助。 – 2016-12-28 13:59:49