Lament: Import is not very smart.

John Roth newsgroups at jhrothjr.com
Wed Jul 14 19:58:42 EDT 2004


"John Lenton" <jlenton at gmail.com> wrote in message
news:mailman.381.1089813781.5135.python-list at python.org...
> On 13 Jul 2004 15:25:50 -0700, Lonnie Princehouse
> <fnord at u.washington.edu> wrote:
> > I don't know if this is a bug or a feature, but it sure is annoying.
> > I apologize if it's already been discussed to death elsewhere (I
> > couldn't find anything).
> >
> > Suppose that you've a package named "foo" which contains module "bar".
> >  Because you're careless, you've also put foo/ into your path...
> >
> > Here's the problem:
> >
> > >> import foo.bar
> > >> import bar
> > >> foo.bar == bar
> > False
> >
> > The second import doesn't recognize that "bar" is already loaded as
> > foo.bar, and loads the module again.  I know it's easy to avoid this
> > by being consistent, but wouldn't be more intuitive if import checked
> > a hash of loaded module filenames before importing something anew?
> > E.g.
> >
> > >> import foo.bar
> > >> import bar
> > >> foo.bar == bar
> > True
> >
> > It's probably too late to change, but it's food for thought.
> >
> > (addendum: I ran into this when isinstance seemingly malfunctioned
> > while I was patching together lots of modules into a cohesive package;
> > turns out there were some instances that had been created from
> > package.module.class and others that were instances of module.class..
> > it took a while to figure out just what the problem was)
>
> pychecker already does similar checks; I don't know if this one in
> particular, but it probably does (I think it checks if you do 'import
> foo' and 'from foo import bar', which is very similar); even if it
> doesn't, that's the place to do it.

I would disagree strongly. First, as one of the posters mentioned,
he's got two different modules with the same name that came from
different directions. A static check would not distinguish this.

More to the point, facilities such as import should just work.
The more complexity you try to hide under the hood, the
more difficult it is to use the language, and that's simply
counter to the stated objectives for Python.

At this point in time, I've come to the conclusion that the whole
notion of "searching a path" is inherently flawed. It's not, of
course, fixable at less than the mythical 3.0 release, but it should
be noted.

John Roth
>
> -- 
> John Lenton (jlenton at gmail.com) -- Random fortune:
> bash: fortune: command not found





More information about the Python-list mailing list