Lament: Import is not very smart.
jlenton at gmail.com
Thu Jul 15 02:29:46 CEST 2004
On Wed, 14 Jul 2004 19:58:42 -0400, John Roth <newsgroups at jhrothjr.com> wrote:
> "John Lenton" <jlenton at gmail.com> wrote in message
> news:mailman.381.1089813781.5135.python-list at python.org...
> > 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 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--- ?
John Lenton (jlenton at gmail.com) -- Random fortune:
bash: fortune: command not found
More information about the Python-list