Project organization and import

[bruno.desthuilliers at gmail.com]

On 5 mar, 01:21, "Martin Unsal" <martinun... at gmail.com> wrote:
> I'm using Python for what is becoming a sizeable project and I'm
> already running into problems organizing code and importing packages.
> I feel like the Python package system, in particular the isomorphism
> between filesystem and namespace,

It's not necessarily a 1:1 mapping. Remember that you can put code in
the __init__.py of a package, and that this code can import sub-
packages/modules namespaces, making the package internal organisation
transparent to user code (I've quite often started with a simple
module, latter turning it into a package as the source-code was
growing too big).

> doesn't seem very well suited for
> big projects. However, I might not really understand the Pythonic way.

cf above.

> I'm not sure if I have a specific question here, just a general plea
> for advice.
>
> 1) Namespace. Python wants my namespace heirarchy to match my
> filesystem heirarchy. I find that a well organized filesystem
> heirarchy for a nontrivial project will be totally unwieldy as a
> namespace. I'm either forced to use long namespace prefixes, or I'm
> forced to use "from foo import *" and __all__, which has its own set
> of problems.

cf above. Also remember that you can "import as", ie:

import some_package.some_subpackage.some_module as some_module

> 1a) Module/class collision. I like to use the primary class in a file
> as the name of the file.

Bad form IMHO. Packages and module names should be all_lower,
classnames CamelCased.

>
> 1b) The Pythonic way seems to be to put more stuff in one file,

Pythonic way is to group together highly related stuff. Not to "put
more stuff".

> but I
> believe this is categorically the wrong thing to do in large projects.

Oh yes ? Why ?

> The moment you have more than one developer along with a revision
> control system,

You *always* have a revision system, don't you ? And having more than
one developper on a project - be it big or small - is quite common.

> you're going to want files to contain the smallest
> practical functional blocks. I feel pretty confident saying that "put
> more stuff in one file" is the wrong answer, even if it is the
> Pythonic answer.

Is this actually based on working experience ? It seems that there are
enough not-trivial Python projects around to prove that it works just
fine.