Lament: Import is not very smart.

John Lenton jlenton at
Thu Jul 15 02:29:46 CEST 2004

On Wed, 14 Jul 2004 19:58:42 -0400, John Roth <newsgroups at> wrote:
> "John Lenton" <jlenton at> wrote in message
> news:mailman.381.1089813781.5135.python-list at
> >
> > 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.

I don't understand what you're saying here (it's late...): the problem
is that 'import' and 'import bar' both bring in the same
module in some situations, and they don't compare as equal. The
problem isn't with and 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", even when
I'm in ''?

> 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--- ?

John Lenton (jlenton at -- Random fortune:
bash: fortune: command not found

More information about the Python-list mailing list