Splitting a module with 8+ classes into a package with each class in its own file

Question

I have a module (tools.py) containing many classes. I'd like to extract these out into its own "whyteboard.tools" package, each class being inside its own file.

However, I previously moved from having all my classes in one base directory to being in a package below the root of my project, and had issues with loading in pickled files that had been saved in the old format. (see: http://stackoverflow.com/questions/2121874). I had to monkey patch the sys.modules dict while loading the file and then delete it afterwards. nasty...

What's the best way to do this move?

Is it best to also import each of my classes in the package's __init__ otherwise I'd have to

from whyteboard.tools.pen import Pen 

instead of

from whyteboard.tools import Pen

Answer 1

What's the best way to do this move?

First. Don't. Class per file isn't going to improve anything, so why bother?

had issues with loading in pickled files that had been saved in the old format

Correct. You must have issues loading files pickled in the old format because the class names have changed.

Why change them if it causes problems?

If you absolutely must change them, you can try something like this to convert. Saves monkey patching. Moves forward to your new architecture.

import this.that.module 
import pickle
import os
legacy_obj= pickle.load( someFile )
os.rename( someFile, someFile+".bak")

import this.that.module.class
new_obj= this.that.module.class( legacy_obj )
pickle.save( someFile )

---

There's a middle ground between 1900 lines in one file and 8+ files with 200+ lines each. A single class of 200+ lines indicates that you may have other design problems. You might want to tackle those first before creating 8 files of "1 class each".

Consider that a 200-line class may already be doing too much. You might want to decompose your classes to have more fine-grained responsibilities. Having done that you may find that you have a few modules -- each with a few classes.

You might want to decompose collections of related classes into reusable modules. A simplistic "class-per-file" approach may be a poor way to restructure this.

Answer 2

I've typically seen the init.py in modules do something like:

from whyteboard.tools.pen import *

This way you can always import from whyteboard.tools and reference any of the classes inside this module without knowing where they are located. You simply need to just know of the classes provided by the whyteboard.tools package.