migrating to packages

Hrvoje Niksic hniksic at xemacs.org
Fri Oct 5 09:52:33 EDT 2007


Gerardo Herzig <gherzig at fmed.uba.ar> writes:

> If the original MYCLASSES.py has 5 different classes ,say A,B,C,D,E
> , each one has to be imported (as A and B) in order to be used for
> the client code. The thing is, there are more than 5 classes, and
> looks like a lot of unnecesary work to me, since a particular
> program can use 1,2, or 3 classes at the time....Thats why im
> watching the way to override the `import statement'.......
>
> Damn client code!!!

You can create both a package and a compatibility module.  The package
would be broken into modules for modularity, while the compatibility
module would import what old code needs from the package, like this:

# old.py:
from new.submodule1 import A, B
from new.submodule2 import C, D
...

Now, old code can keep using "from old import A" and such, while new
code would import new.submodule1, new.submodule2, etc., as necessary.

Old code is no worse off because, although it uses the compatibility
module that just imports everything, that is in essence what the
previous module did as well.  On the other hand, new code can make use
of the modularity and reduce load times by only importing what it
really needs.



More information about the Python-list mailing list