The Pythonic way of organizing modules and packages

Question

I come from a background where I normally create one file per class. I organize common classes under directories as well. This practice is intuitive to me and it has been proven to be effective in C++, PHP, JavaSript, etc.

I am having trouble bringing this metaphor into Python: files are not just files anymore, but they are formal modules. It doesn't seem right to just have one class in a module --- most classes are useless by themselves. If I have a automobile.py and an Automobile class, it seems silly to always reference it as automobile.Automobile as well.

But, at the same time, it doesn't seem right to throw a ton of code into one file and call it a day. Obviously, a very complex application should have more than 5 files.

What is the correct---or pythonic---way? (Or if there is no correct way, what is your preferred way and why?) How much code should I be throwing in a Python module?

• S.Lott: Duplicate: stackoverflow.com/questions/1642975/…
• S.Lott: Duplicate: stackoverflow.com/questions/106896/…
• 303: The C++ Core Guidelines actually advise against the practice of creating one file per class.

Answer 1

Think in terms of a "logical unit of packaging" -- which may be a single class, but more often will be a set of classes that closely cooperate. Classes (or module-level functions -- don't "do Java in Python" by always using static methods when module-level functions are also available as a choice!-) can be grouped based on this criterion. Basically, if most users of A also need B and vice versa, A and B should probably be in the same module; but if many users will only need one of them and not the other, then they should probably be in distinct modules (perhaps in the same package, i.e., directory with an __init__.py file in it).

The standard Python library, while far from perfect, tends to reflect (mostly) reasonably good practices -- so you can mostly learn from it by example. E.g., the threading module of course defines a Thread class... but it also holds the synchronization-primitive classes such as locks, events, conditions, and semaphores, and an exception-class that can be raised by threading operations (and a few more things). It's at the upper bound of reasonable size (800 lines including whitespace and docstrings), and some crucial thread-related functionality such as Queue has been placed in a separate module, nevertheless it's a good example of what maximum amount of functionality it still makes sense to pack into a single module.

Answer 2

If you want to stick to your one-class-per-file system (which is logical, don't get me wrong), you might do something like this to avoid having to refer to automobile.Automobile:

from automobile import Automobile
car = Automobile()

However, as mentioned by cobbal, more than one class per file is pretty common in Python. Either way, as long as you pick a sensible system and use it consistently, I don't think any Python users are going to get mad at you :).

Answer 3

If you are coming from a c++ point of view, you could view python modules akin to a .so or .dll. Yeah they look like source files, because python is scripted, but they are actually loadable libraries of specific functionality.

Another metaphor that may help is you might look python modules as namespaces.

Answer 4

In a mid-sized project, I found myself with several sets of closely related classes. Several of those sets are now grouped into files; for example, the low-level network classes are all in a single network module. However, a few of the largest classes have been split out into their own file.

Perhaps the best way to start down that path from a one-class-per-file history is to take the classes that you would normally place in the same directory, and instead keep them in the same file. If that file starts looking too large, split it.

Answer 5

As a vague guideline: more than 1 class per file is the norm for python

also, see How many Python classes should I put in one file?