我会说，在这个文件中放入尽可能多的逻辑分组的类，而不会使它太大太复杂。

我碰巧喜欢Java模型，原因如下。将每个类放在单独的文件中，可以在浏览源代码时更容易看到类，从而促进重用。如果您将一堆类分组到一个文件中，其他开发人员可能不会很明显地发现其中有一些类可以通过浏览项目的目录结构来重用。因此，如果您认为您的类可能被重用，我将把它放在自己的文件中。

我会说，在这个文件中放入尽可能多的逻辑分组的类，而不会使它太大太复杂。

由于没有人为的限制，它实际上取决于什么是可理解的。如果你有一堆逻辑上分组在一起的相当短、简单的类，那就把它们扔进去。如果你有大、复杂的类，或者作为一个组没有意义的类，每个类一个文件。或者选择介于两者之间的东西。随着事情的变化而重构。

这完全取决于项目有多大，类有多长，是否将从其他文件中使用它们等等。

例如，我经常使用一系列的类来进行数据抽象——所以我可能有4或5个类，它们可能只有1行长(类SomeData: pass)。

将它们分开到单独的文件中是愚蠢的——但由于它们可能从不同的文件中使用，将所有这些放在单独的data_model.py文件中是有意义的，所以我可以从mypackage中进行。data_model导入SomeData, someesubdata

如果您有一个包含大量代码的类，其中可能只有一些它使用的函数，那么将这个类和辅助函数分离到一个单独的文件中将是一个好主意。

你应该从mypackage.database.schema导入MyModel，而不是从mypackage.email.errors导入MyDatabaseModel——如果你从哪里导入东西是有意义的，并且文件不是数万行长，那么你已经正确地组织了它。

Python Modules文档中有一些关于组织包的有用信息。

当我对庞大的文件感到恼火时，当理想的关联结构开始自然出现时，我发现自己把东西分开了。通常这两个阶段似乎是同时发生的。

如果你过早地将事情分开，这可能会非常烦人，因为你开始意识到需要完全不同的结构顺序。

另一方面，当任何.java或.py文件超过700行时，我开始不断地试图记住“那个特定的位”在哪里。

对于Python/Jython, import语句的循环依赖关系似乎也发挥了作用:如果你试图将太多合作的基本构建块分割到单独的文件中，这种语言的“限制”/“不完善”似乎迫使你将事物分组，也许是一种相当明智的方式。

至于分解成包，我真的不知道，但我想说可能同样的烦恼规则和快乐结构的出现适用于所有级别的模块化。