My studies of code design have mostly been in Ruby because there are few advanced resources available in Python. I gradually began to assume that well-designed code in any language exists in short, 20-40 line source files, and started to organize my Python code the same way.
However, a coworker recently told me that my source files were not “Pythonic” because they were too short. Dismayed, I referred to The Zen of Python and PEP8, and found no mention of the optimal size of a source code file. In fact, I interpreted the cryptic final line of Zen, which calls for “More Namespaces”, as a decree that programmers break their code into many distinct modules.
I then went to Github and noticed that most Python source files in mature projects, such as Django and Tornado, were three hundred to eight hundred lines long, whereas Ruby source files, like those found in Rails, were rarely more than one hundred lines long.
Why do Python programmers universally write longer source files, despite there being no specific dictum from Guido to do so? The answer lies in the packaging system.
The ‘import’ statement in Python allows users to select individual functions or classes from a file to include in the top-level namespace. However, when you import a file with the ‘require’ directive in Ruby, all of the top-level identifiers in that file are merged into the current file’s namespace.
Short source files defining only one class are how Ruby programmers accommodate this restriction.
I believe that there are other benefits to short source files, such as easier version control, as well as discouragement against writing bloated classes and functions - but the Pythonic approach encourages source files at least three hundred lines long, and files over one thousand lines are not a problem.