Project organization and import

[Chris Mellon]

On 6 Mar 2007 09:09:13 -0800, Martin Unsal <martinunsal at gmail.com> wrote:
> On Mar 6, 6:07 am, "Chris Mellon" <arka... at gmail.com> wrote:
> > Because you're advocating single class per file.
>
> What I actually said was "Smallest practical functional block." I
> never said one class per file, in fact I generally have more than one
> class per file. Nonetheless I frequently have a class which has the
> same name as the file it's contained in, which is where I start having
> trouble.

You do? Or do you only have trouble because you don't like using "from
foo import Foo" because you need to do more work to reload such an
import?

>
> > What you said was  A scan through the
> > standard library may be instructive, where there are some modules that
> > expose a single class (StringIO, pprint) and others that expose many,
> > and some that expose none at all.
>
> AHA! Here we see the insidious Python package system at work! ;)
>
> I said "file" and you assume that I am talking about the exposed
> namespace. Files should not have to be isomorphic with namespace! A
> package that exposes many classes may still use one class per file if
> it wants to.
>

What makes you think that the exposed namespace has to be isomorphic
with the filesystem? Further, why do you think doing so is bad? People
do it because it's convenient and simple, not because its necessary.
Why don't you like filesystems?

> > In any
> > case, as I hinted at, I prefer an organic, developer driven approach
> > to deciding these things, not handed down from above style guidelines.
>
> PRECISELY. And in the case of Python, package stucture is dictated,
> not by a style guideline, but by the design flaws of Python's package
> system.
>

What design flaws are those? Is it because you're trying to have
packages as part of your project without installing them on your
PYTHONPATH somewhere?

If you want to break a module internally into multiple files, then
make it a package. To an importer, they're almost indistinguishable.
If you want to break a module into multiple packages and then stick
the files that make up the package in bizarre spots all over the
filesystem, can you give a reason why?