Simplifying imports?

[Terry Hancock]

On Tuesday 13 September 2005 12:46 pm, George Sakkis wrote:
> "Terry Hancock" <hancock at anansispaceworks.com> wrote:
> > On Monday 12 September 2005 10:09 pm, chapolim-colorado at bol.com.br wrote:
> > > I like to keep my classes each in a separate file with the same name of
> > > the class. 
> > Apparently "foo" is already a package defined using __init__.py,
> > so you know about that part already.
> >
> > Just change its contents to read:
> >
> > from Bar import Bar
> > from Blah import Blah
> > from Zzz import Zzz
> 
> If you do this often or have lots of classes you want to import this
> way, you could automate it:

(nice)

> [...]
> Or even better, forget about the braindead java restriction of one
> class per file and organize your code as it makes more sense to you.

While this is good sound Python advice, there are good Human-readability
reasons for keeping a small number of classes per module. Python classes
certainly may not tend to blossum into the verbosity of their Java
counterparts, but I've still seen some pretty chunky classes (e.g. in
the Zope sources).   So, the __init__.py approach and packaging is
still a good idea.

I particularly like the ability of __init__.py to craft the interface
layout of the module, independently of the file-structure that you
choose, as the best layout for the user may not be the best layout
for the developer.

I personally wouldn't favor automating this process unless you are
actually working with some kind of "plugin" design pattern. It's nicer
to have the fine control over the interface and be able to pick and
choose how things should be laid out. And the __init__.py code then
serves as a map for the developer to figure out where things are stored
(yes, they could also use grep, but every little bit helps).


--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com