I'm freshly coming to the Python world after years of Java and PHP. While the language itself is pretty much straightforward, I'm struggling with some 'minor' issues that I can't wrap my head around — and to which I couldn't find answers in the numerous documents and tutorials I've read this far.
To the experienced Python practitioner, this question might seem silly, but I really want an answer to it so I can go further with the language:
In Java and PHP (although not strictly required), you are expected to write each class
on its own file, with file's name is that of the class
as a best practice.
But in Python, or at least in the tutorials I've checked, it is ok to have multiple classes in the same file.
Does this rule hold in production, deployment-ready code or it's done just for the sake of brevity in educative-only code?
Best Answer
Yes. Both from a philosophical perspective as well as a practical one.
In Python, modules are a namespace that exist once in memory.
Say we had the following hypothetical directory structure, with one class defined per file:
All of these classes are available in the
collections
module and (there are, in fact, 25 in total) defined in the standard library module in_collections_abc.py
There are a couple of issues here that I believe makes the
_collections_abc.py
superior to the alternative hypothetical directory structure.Are you prevented from breaking groups of classes into different modules when you find it desirable from a namespacing and organizational perspective?
No.
From the Zen of Python , which reflects the philosophy and principles under which it grew and evolved:
But let us keep in mind that it also says:
Python is incredibly clean and easy to read. It encourages you to read it. Putting every separate class in a separate file discourages reading. This goes against the core philosophy of Python. Look at the structure of the Standard Library, the vast majority of modules are single-file modules, not packages. I would submit to you that idiomatic Python code is written in the same style as the CPython standard lib.
Here's the actual code from the abstract base class module. I like to use it as a reference for the denotation of various abstract types in the language.
Would you say that each of these classes should require a separate file?
So should they each have their own file?
I hope not.
These files are not just code - they are documentation on the semantics of Python.
They are maybe 10 to 20 lines on average. Why should I have to go to a completely separate file to see another 10 lines of code? That would be highly impractical. Further, there would be nearly identical boilerplate imports on each file, adding more redundant lines of code.
I find it quite useful to know that there is a single module where I can find all of these Abstract Base Classes, instead of having to look over a list of modules. Viewing them in context with each other allows me to better understand them. When I see that an Iterator is an Iterable, I can quickly review what an Iterable consists of by glancing up.
I sometimes wind up having a couple of very short classes. They stay in the file, even if they need to grow larger over time. Sometimes mature modules have over 1000 lines of code. But ctrl-f is easy, and some IDE's make it easy to view outlines of the file - so no matter how large the file, you can quickly go to whatever object or method that you're looking for.
Conclusion
My direction, in the context of Python, is to prefer to keep related and semantically similar class definitions in the same file. If the file grows so large as to become unwieldy, then consider a reorganization.