Lament: Import is not very smart.

[Lonnie Princehouse]

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

 

[Greg Ewing]

Suppose that you've a package named "foo" which contains module "bar".
Because you're careless, you've also put foo/ into your path...

The solution to that is not to be careless (i.e. don't
put overlapping entries into your path).

 

[John Roth]

The solution to that is not to be careless (i.e. don't
put overlapping entries into your path).

Sometimes it isn't carelessness. You wouldn't believe the
amount of trouble that caused me with the FIT port.

John Roth

 

[Steve]

Hi,

Here's the problem:

False

This might seem like a problem in this specific case, for this
specific problem, but consider this:

where commonlib is a module I happened to write before I knew that
foo.commonlib existed (which does something entirely different but is
coincidently named in the similar manner.)

I'd be *very* grateful if

 

[Steve]

Sorry, I spoke without thinking:

but does
solve the problem ??

Regards
Steve

 

[John Lenton]

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:

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.

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.

 

[Lonnie Princehouse]

This might seem like a problem in this specific case, for this
specific problem, but consider this:


where commonlib is a module I happened to write before I knew that
foo.commonlib existed (which does something entirely different but is
coincidently named in the similar manner.)

I'd be *very* grateful if

I'm advocating checking the absolute filepath first, such that:

....would be True iff commonlib.py is in the foo package's directory
(hence is rightfully part of the foo package).

 

[Lonnie Princehouse]

Aha! Someone else has been boggled by this too. It's an easy problem
to avoid in simple code, but much more difficult once one starts doing
esoteric things with __import__ and sys.path...

 

[John Roth]

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]

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.

I don't understand what you're saying here (it's late...): the problem
is that 'import foo.bar' and 'import bar' both bring in the same
module in some situations, and they don't compare as equal. The
problem isn't with foo.bar and baz.bar both being imported as bar and
comparing as equal---or am I missing something (again)?

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.

you mean we should always have to say "import foo.bar.baz", even when
I'm in 'foo.bar'?

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.

if it is the above what you mean by 'the whole notion of "searching a
path"', I guess I can live with that. But if you mean we should drop
sys.path altogether--- ?

 

[Antoon Pardon]

The solution to that is not to be careless (i.e. don't
put overlapping entries into your path).

Oh come on. When people ask for certain features, those are
denied with the argument that they will introduce subtle bugs
that will be hard to find.

Now here we have something that can introduce subtle bugs that
can be hard to find and the response is: don't be careless.

 

[Lonnie Princehouse]

you mean we should always have to say "import foo.bar.baz", even when

I'm in 'foo.bar'?

PEP 328 clarifies relative/absolute imports. It should be available
in the 2.4a release via "from __future__ import absolute_import"

(http://www.python.org/peps/pep-0328.html)

 

[John Lenton]

PEP 328 clarifies relative/absolute imports. It should be available
in the 2.4a release via "from __future__ import absolute_import"

excellent!

 

[Nicolas Fleury]

I'm advocating checking the absolute filepath first, such that:

PEP 328 will fix that

Regards,
Nicolas