Project organization and import

[Chris Mellon]

On 6 Mar 2007 08:42:00 -0800, Martin Unsal <martinunsal at gmail.com> wrote:
> On Mar 5, 2:18 pm, Bruno Desthuilliers
> <bdesth.quelquech... at free.quelquepart.fr> wrote:
> > Martin Unsal a écrit :
> > > 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.
> >
> > Some of us still manage to do so without messing with PYTHONPATH.
>
> How exactly do you manage it?
>
> The only way I can see to do it is to have widgets/__init__.py look
> something like this:
>
> from common import util
> from scrollbar import Scrollbar
> from form import Form
>
> Then Scrollbar.py doesn't have to worry about importing util, it just
> assumes that util is already present in its namespace.
>
> BUT ... this means that Scrollbar.py can only be loaded in the
> interpreter as part of package "widgets". You can't run an interpreter
> and type "import widgets.scrollbar.Scrollbar" and start going to town,
> because Scrollbar doesn't import its own dependencies.
>
> So what I want to clarify here: Do Python programmers try to design
> packages so that each file in the package can be individually loaded
> into the interpreter and will automatically import its own
> dependencies? Or do you design packages so they can only be used by
> importing from the top level and running the top level __init__.py?
>
> I hope that made sense. :)
>

Scrollbar *can't* assume that util will be present in its namespace,
because it won't be unless it imports it. Scrollbar needs to import
its own dependencies. But why do you think thats a problem?

> Martin
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>