Splitting up large python module impact on performance?

[Rick Johnson]

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.