Project organization and import

[Martin Unsal]

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.

> 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.

> 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.

Martin