Project organization and import

[Martin Unsal]

On Mar 5, 12:45 am, "bruno.desthuilli... at gmail.com"
<bruno.desthuilli... at gmail.com> wrote:
> 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

Sure, but that doesn't solve the problem.

Say you have a package "widgets" with classes ScrollBar, Form, etc.
You want the end user to "import widgets" and then invoke
"widgets.ScrollBar()". As far as I know there are only two ways to do
this, both seriously flawed: 1) Put all your code in one module
widgets.py, 2) use "from scrollbar import *" in widgets/__init__.py,
which is semi-deprecated and breaks reload().

> Also remember that you can "import as", ie:
>
> import some_package.some_subpackage.some_module as some_module

Sure but that doesn't eliminate the unfortunate interaction between
Python class organization and filesystem heirarchy. For example, say
you want to organize the widgets package as follows:

widgets/scrollbar/*.py
widgets/form/*.py
widgets/common/util.py

Other than messing around with PYTHONPATH, which is horrible, I don't
see how to import util.py from the widget code.

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

You're still stuck doing foo.Foo() everywhere in your client code,
which is ugly and wastes space, or using "from foo import *" which is
broken.

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

For myriad reasons, just one of them being the one I stated -- smaller
files with one functional unit each are more amenable to source code
management with multiple developers.

We could discuss this till we're blue in the face but it's beside the
point. For any given project, architecture, and workflow, the
developers are going to have a preference for how to organize the code
structurally into files, directories, packages, etc. The language
itself should not place constraints on them. The mere fact that it is
supposedly "Pythonic" to put more functionality in one file indicates
to me that the Python package system is obstructing some of its users
who have perfectly good reasons to organize their code differently.

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

Yes. I've worked extensively on several projects in several languages
with multi-million lines of code and they invariably have coding
styles that recommend one functional unit (such as a class), or at
most a few closely related functional units per file.

In Python, most of the large projects I've looked at use "from foo
import *" liberally.

I guess my question boils down to this. Is "from foo import *" really
deprecated or not? If everyone has to use "from foo import *" despite
the problems it causes, how do they work around those problems (such
as reloading)?

Martin