A Python file is called a "module" and it's one way to organize your software so that it makes "sense". Another is a directory, called a "package".
A module is a distinct thing that may have one or two dozen closely-related classes. The trick is that a module is something you'll import, and you need that import to be perfectly sensible to people who will read, maintain and extend your software.
The rule is this: a module is the unit of reuse.
You can't easily reuse a single class. You should be able to reuse a module without any difficulties. Everything in your library (and everything you download and add) is either a module or a package of modules.
For example, you're working on something that reads spreadsheets, does some calculations and loads the results into a database. What do you want your main program to look like?
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 )
Think of the import as the way to organize your code in concepts or chunks. Exactly how many classes are in each import doesn't matter. What matters is the overall organization that you're portraying with your import statements.
Since there is no artificial limit, it really depends on what's comprehensible. If you have a bunch of fairly short, simple classes that are logically grouped together, toss in a bunch of 'em. If you have big, complex classes or classes that don't make sense as a group, go one file per class. Or pick something in between. Refactor as things change.
It entirely depends on how big the project is, how long the classes are, if they will be used from other files and so on.
For example I quite often use a series of classes for data-abstraction - so I may have 4 or 5 classes that may only be 1 line long (class SomeData: pass).
It would be stupid to split each of these into separate files - but since they may be used from different files, putting all these in a separate data_model.py file would make sense, so I can do from mypackage.data_model import SomeData, SomeSubData
If you have a class with lots of code in it, maybe with some functions only it uses, it would be a good idea to split this class and the helper-functions into a separate file.
You should structure them so you do from mypackage.database.schema import MyModel, not from mypackage.email.errors import MyDatabaseModel - if where you are importing things from make sense, and the files aren't tens of thousands of lines long, you have organised it correctly.
I happen to like the Java model for the following reason. Placing each class in an individual file promotes reuse by making classes easier to see when browsing the source code. If you have a bunch of classes grouped into a single file, it may not be obvious to other developers that there are classes there that can be reused simply by browsing the project's directory structure. Thus, if you think that your class can possibly be reused, I would put it in its own file.
I find myself splitting things up when I get annoyed with the bigness of files and when the desirable structure of relatedness starts to emerge naturally. Often these two stages seem to coincide.
It can be very annoying if you split things up too early, because you start to realise that a totally different ordering of structure is required.
On the other hand, when any .java or .py file is getting to more than about 700 lines I start to get annoyed constantly trying to remember where "that particular bit" is.
With Python/Jython circular dependency of import statements also seems to play a role: if you try to split too many cooperating basic building blocks into separate files this "restriction"/"imperfection" of the language seems to force you to group things, perhaps in rather a sensible way.
As to splitting into packages, I don't really know, but I'd say probably the same rule of annoyance and emergence of happy structure works at all levels of modularity.
发布评论
评论（6）
Python 文件称为“模块”，它是组织软件使其变得“有意义”的一种方式。 另一种是目录，称为“包”。
模块是一个独特的东西，可能有一两个密切相关的类。 诀窍在于，模块是您要导入的东西，并且您需要该导入对于将阅读、维护和扩展您的软件的人来说是完全敏感的。
规则是这样的：模块是重用的单位。
您无法轻松地重用单个类。 您应该能够毫无困难地重用模块。 库中的所有内容（以及您下载和添加的所有内容）都是一个模块或模块包。
例如，您正在开发读取电子表格、进行一些计算并将结果加载到数据库中的功能。 你希望你的主程序是什么样的？
将导入视为按概念或块组织代码的方式。 每个导入中到底有多少个类并不重要。 重要的是您使用
import语句描绘的整个组织。A Python file is called a "module" and it's one way to organize your software so that it makes "sense". Another is a directory, called a "package".
A module is a distinct thing that may have one or two dozen closely-related classes. The trick is that a module is something you'll import, and you need that import to be perfectly sensible to people who will read, maintain and extend your software.
The rule is this: a module is the unit of reuse.
You can't easily reuse a single class. You should be able to reuse a module without any difficulties. Everything in your library (and everything you download and add) is either a module or a package of modules.
For example, you're working on something that reads spreadsheets, does some calculations and loads the results into a database. What do you want your main program to look like?
Think of the import as the way to organize your code in concepts or chunks. Exactly how many classes are in each import doesn't matter. What matters is the overall organization that you're portraying with your
importstatements.由于没有人为的限制，这实际上取决于可理解的内容。 如果您有一堆相当短、简单的类，它们在逻辑上分组在一起，那么就将它们扔进去。 如果您有大型、复杂的类或作为一个组没有意义的类，请为每个类创建一个文件。 或者选择介于两者之间的东西。 随着事情的变化进行重构。
Since there is no artificial limit, it really depends on what's comprehensible. If you have a bunch of fairly short, simple classes that are logically grouped together, toss in a bunch of 'em. If you have big, complex classes or classes that don't make sense as a group, go one file per class. Or pick something in between. Refactor as things change.
这完全取决于项目有多大、类有多长、是否从其他文件中使用它们等等。
例如，我经常使用一系列类进行数据抽象 - 因此我可能有 4 或 5 个类，它们可能只有 1 行长（
class SomeData: pass）。将每个文件拆分为单独的文件是愚蠢的 - 但由于它们可能在不同的文件中使用，因此将所有这些文件放入单独的
data_model.py文件中是有意义的，所以我可以这样做from mypackage.data_model import SomeData, SomeSubData如果您有一个包含大量代码的类，也许只有它使用一些函数，那么最好将此类和辅助函数拆分为一个单独的文件。
您应该构建它们，以便您执行
from mypackage.database.schema import MyModel，而不是from mypackage.email.errors import MyDatabaseModel- 如果您从何处导入内容有意义，而且文件的长度不是几万行，您已经正确组织了它。Python 模块文档 提供了一些有关组织包的有用信息。
It entirely depends on how big the project is, how long the classes are, if they will be used from other files and so on.
For example I quite often use a series of classes for data-abstraction - so I may have 4 or 5 classes that may only be 1 line long (
class SomeData: pass).It would be stupid to split each of these into separate files - but since they may be used from different files, putting all these in a separate
data_model.pyfile would make sense, so I can dofrom mypackage.data_model import SomeData, SomeSubDataIf you have a class with lots of code in it, maybe with some functions only it uses, it would be a good idea to split this class and the helper-functions into a separate file.
You should structure them so you do
from mypackage.database.schema import MyModel, notfrom mypackage.email.errors import MyDatabaseModel- if where you are importing things from make sense, and the files aren't tens of thousands of lines long, you have organised it correctly.The Python Modules documentation has some useful information on organising packages.
我碰巧喜欢 Java 模型，原因如下。 将每个类放在单独的文件中可以使浏览源代码时更容易看到类，从而促进重用。 如果您将一堆类分组到一个文件中，那么其他开发人员可能并不明显知道其中的类可以通过浏览项目的目录结构来重用。目录结构。 因此，如果您认为您的类可以重用，我会将其放在自己的文件中。
I happen to like the Java model for the following reason. Placing each class in an individual file promotes reuse by making classes easier to see when browsing the source code. If you have a bunch of classes grouped into a single file, it may not be obvious to other developers that there are classes there that can be reused simply by browsing the project's directory structure. Thus, if you think that your class can possibly be reused, I would put it in its own file.
当我对太大的文件感到恼火以及当理想的相关性结构开始自然出现时，我发现自己会把事情分开。 通常这两个阶段似乎是重合的。
如果你过早地拆分事物，可能会非常烦人，因为你开始意识到需要完全不同的结构顺序。
另一方面，当任何 .java 或 .py 文件超过大约 700 行时，我开始感到恼火，不断地试图记住“那个特定位”在哪里。
对于 Python/Jython，导入语句的循环依赖似乎也发挥了作用：如果您尝试将太多协作的基本构建块拆分为单独的文件，那么语言的这种“限制”/“不完美”似乎会迫使您将事物分组，也许以一种相当明智的方式。
至于分成包，我真的不知道，但我想说可能相同的烦恼规则和快乐结构的出现适用于所有级别的模块化。
I find myself splitting things up when I get annoyed with the bigness of files and when the desirable structure of relatedness starts to emerge naturally. Often these two stages seem to coincide.
It can be very annoying if you split things up too early, because you start to realise that a totally different ordering of structure is required.
On the other hand, when any .java or .py file is getting to more than about 700 lines I start to get annoyed constantly trying to remember where "that particular bit" is.
With Python/Jython circular dependency of import statements also seems to play a role: if you try to split too many cooperating basic building blocks into separate files this "restriction"/"imperfection" of the language seems to force you to group things, perhaps in rather a sensible way.
As to splitting into packages, I don't really know, but I'd say probably the same rule of annoyance and emergence of happy structure works at all levels of modularity.
我想说的是，在该文件中放置尽可能多的可以逻辑分组的类，而不会使它太大和复杂。
I would say to put as many classes as can be logically grouped in that file without making it too big and complex.