我习惯了Java模型，每个文件可以有一个公共类。 Python没有此限制，我想知道组织类的最佳实践是什么。

解决方案

我要说的是，在该文件中放置尽可能多的类，这些类可以在逻辑上分组，而又不会使其变得太大和太复杂。

由于没有人为的限制，所以它实际上取决于可理解的内容。如果我们有一堆在逻辑上组合在一起的相当短，简单的类，则扔一堆'em。如果我们有大型，复杂的类或者没有整体意义的类，请为每个类编写一个文件。或者在两者之间选择一些东西。随着情况的变化进行重构。

Python文件称为"模块"，它是组织软件以使其具有"感觉"的一种方式。另一个是目录，称为"包"。

模块是一个独特的事物，可能具有一到两个紧密相关的类。诀窍在于，我们将要导入一个模块，并且我们需要该导入对将要阅读，维护和扩展软件的人们完全敏感。

规则是这样的：模块是重用的单位。

我们无法轻松地重用单个类。我们应该能够毫无困难地重用模块。库中的所有内容(以及下载和添加的所有内容)都是模块或者模块包。

例如，我们正在做的工作是读取电子表格，进行一些计算并将结果加载到数据库中。我们希望主程序是什么样的？

from ssReader import Reader
from theCalcs import ACalc, AnotherCalc
from theDB import Loader

def main( sourceFileName ):
    rdr= Reader( sourceFileName )
    c1= ACalc( options )
    c2= AnotherCalc( options )
    ldr= Loader( parameters )
    for myObj in rdr.readAll():
        c1.thisOp( myObj )
        c2.thatOp( myObj )
        ldr.laod( myObj )

将导入视为以概念或者大块形式组织代码的方式。每次导入中到底有多少个类并不重要。重要的是我们要在import语句中描绘的整体组织。

这完全取决于项目的规模，类的时长，是否可以从其他文件中使用它们等等。

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

将这些文件拆分成单独的文件是很愚蠢的，但是由于可以从不同的文件中使用它们，因此将所有这些文件放入一个单独的data_model.py文件中是有道理的，因此我可以从mypackage.data_model import SomeData中进行操作， SomeSubData`

如果类中包含大量代码，也许只使用了某些函数，那么将此类和辅助函数拆分为一个单独的文件将是一个好主意。

我们应该对它们进行结构化，以便从有意义的位置导入文件并且文件不是成千上万行时，从mypackage.database.schema导入MyModel，而不是从mypackage.email.errors导入MyDatabaseModel。很久以来，我们已经正确地组织了它。

Python模块文档提供了一些有关组织软件包的有用信息。