Importing dynamically loaded modules (in packages)?

[Steve Holden]

"holger krekel" <pyth at devel.trillke.net> wrote in message
news:mailman.1020262266.572.python-list at python.org...
> On Wed, May 01, 2002 at 03:30:16AM +0200, Irmen de Jong wrote:
> > "holger krekel" <pyth at devel.trillke.net> wrote in message
> > news:mailman.1020213066.536.python-list at python.org...
> >
> > > > "import Package.TestModule" still doesn't work: ""no module named
> > TestModule""
> > > > How can I correct this?
> > >
> > >     sys.modules['Package.TestModule'] = TestModule
> > >
> > > after that you should be able to do
> > >
> > >     import Package.TestModule
> >
> > Ouch... isn't that cheating? I mean, the Module name is "TestModule",
> > not "Package.TestModule".
>
> Yes, it's the blessed way of cheating, though.
> See 'os' and 'os.path' for example.
>
> The package concept falls a bit out of python.
> After rereading the docs at
> http://www.python.org/doc/essays/packages.html
> it doesn't feel like a thoroughly thought out concept
> (compared to so many other things in python).
>
The central quote to focus on appears to be

"""Note that when using "from package import item", the item can be either a
submodule (or subpackage) of the package, or some other name defined in a
the package, like a function, class or variable. The import statement first
tests whether the item is defined in the package; if not, it assumes it is a
module and attempts to load it. If it fails to find it, ImportError is
raised.
Contrarily, when using syntax like "import item.subitem.subsubitem", each
item except for the last must be a package; the last item can be a module or
a package but can't be a class or function or variable defined in the
previous item.""" [Quotes added to replace emphasis in this non-formatted
version].

> There is no 'package' object to start with and package
> functionalities are not encapsulated anywhere.
> So it seems approriate to think of a package as a
> concept of nested modules and accessing them with
> respect to directory structure and filesystem-coupled
> initialization.
>
A package is a directory containing an __init__.py file. When the package is
imported (which mjust happen before any submodules or subpackages can be
imported) the __init__.py file is executed. At its simplest this file can be
empty. It might also set the "__all__" special attribute to indicate exactly
those names which should be imported by the stamement "from module import
*". At its most complex it can set up huge data structures whose presence
its sub-modules and sub-packages are going to take for granted.

> imho Python3 should have a better grip
> on packages.
>
imho Motherhood and apple-pie are good ;-)

Anything that makes Python applications easier to package and distribute
will be a good thing. "Python 3 should have a better grip on packages" comes
nowhere near making Python applications easier to package and distribute ;-)

> Is their already something underway?

There have been lots of attempts to mess with module import mechanisms, some
less successful than others. Probably the most important requirement is
better documentation. As I pointed out earlier this week, it doesn't help to
have the documentation say things like "[XXX can't be bothered to spell all
this out]". I would guess that probably Gordon McMillan knows more about the
import mechanism than most, but he's pretty busy keeping his installer up to
date.

> Does anybody disagree?
>
That motherhood and apple pie are good? Who could possibly disagree?

a-better-question-is-who's-going-to-do-something-about-it-ly y'rs  - steve
--

Steve Holden: http://www.holdenweb.com/ ; Python Web Programming:
http://pydish.holdenweb.com/pwp/