Bill Deegan wrote: > I'm doing some refactoring on a fairly large python > codebase. Some of the files are > 4000 lines long and > contain many classes.
I would argue that files of such size are a total pain to navigate and thus, edit. I prefer to place only one -- or only a handful of classes -- in each file. One class per file is _most_ preferred. But if you have a small group of classes that are closely dependent on one another, and, the source definitions can fit comfortably in a single file, well then, i say do it. You just have to decide what is comfortable for _you_; your coworkers; and anyone who may be forced to maintain your code in the future. When in doubt, and when it comes to style issues, there is one universal rule you should always strive to follow, and that rule is to be _consistent_. PEP8 underscores the importance of consistency, and you may want to read it. > Should I expect any performance hit from splitting some of > the classes out to other files? I think you should worry less about the startup performance hit and more about the possibility of circular imports. I'm not a big fan of Python's import or packaging systems, as neither mesh nicely with my style of programming. But i've found some ways to work around them... So if you're using the OOP paradigm (like i am), and if you write your OOP code in a strict formal style (hail java!), then you can leverage some of the machinery of OOP to get _around_ the limitations inherent in the aforementioned components of the Python language. I may exaggerate on this a bit more if you're interested. -- https://mail.python.org/mailman/listinfo/python-list
