Project organization and import

[Chris Mellon]

On 6 Mar 2007 09:49:55 -0800, Martin Unsal <martinunsal at gmail.com> wrote:
> On Mar 6, 9:19 am, "Chris Mellon" <arka... at gmail.com> wrote:
> > 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?
>
> More work, like rewriting __import__ and reload??? :)
>
> There's a point where you should blame the language, not the
> programmer. Are you saying I'm lazy just because I don't want to mess
> with __import__?

You have to reload the importing module as well as the module that
changed. That doesn't require rewriting the import infrastructure.
It's only an issue because you're changing things at one level but
you're trying to use them at a level removed from that. I never work
that way, because I only have any need or desire to reload when I'm
working interactively and I when I'm doing that I work directly with
the modules I'm changing. The interfaces are what my unit tests are
for. If you're doing stuff complicated and intricate enough in the
interpreter that you need reload() to do very much more than its
doing, then you're working poorly - that sort of operation should be
in a file you can run and test automatically.

>
> > What makes you think that the exposed namespace has to be isomorphic
> > with the filesystem?
>
> I don't; you do!
>
> I was clearly talking about files and you assumed I was talking about
> namespace. That's Pythonic thinking... and I don't mean that in a good
> way!
>

All the files on the PYTHONPATH will map into the namespace. However,
you can have items in the namespace that do not map to files. The main
reasons to do so are related to deployment, not development though so
I wonder why you want to.

> > 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?
>
> Because I have written a project with 50,000 lines of Python and I'm
> trying to organize it in such a way that it'll scale up cleanly by
> another order of magnitude. Because I've worked on projects with
> millions of lines of code and I know about how such things are
> organized. It's funny, I'm a newbie to Python but it seems like I'm
> one of the only people here thinking about it as a large scale
> development language rather than a scripting language.
>

Thats not answering the question. Presumably you have some sort of
organization for your code in mind. What about that organization
doesn't work for Python? If you want multiple files to map to a single
module, make them a package.