[Python-Dev] Relative import

[Tim Peters]

[Barry]
> ...
> I'll just note that where the current status quo trips /me/ up most is
> when I accidentally have a local module with the same name as a global
> module, and then I write an import statement expecting to get the
> standard library module, but end up getting the local module.

Indeed, this is common on c.l.py and the Tutor lists, with a twist:  someone
writes a module in their *current* directory, with a name like random.py,
and then "Python breaks mysteriously all over the place", because every
import of random ends up with something utterly unexpected.  For some
reason, "random.py" seems most often to be the actual name used in these
cases.

Possibly related:  I remember pissing away a day a year or so ago trying to
track down a segfault in a Zope test that happened only when I ran the test
on my McLean box.  In the end, it turned out that the test in question was
(after untangling the usual layers of Zopish indirection <wink/grrrr>)
deliberately trying to import a module that didn't exist, with an oddball
name.  It just so happened that somebody had whittled down a segfaulting
Python program and uploaded it to SourceForge, with the very same oddball
name.  I had downloaded that program into my Python build directory, and
Zope kept provoking its segfault as a side effect of (unintentionally!)
importing it.

In large part, I've come to loathe imports -- I never have the foggiest idea
how they're going to get satisfied in code I didn't write, and especially in
code that plays every trick in (and out) of the book to hide what it's
really doing with sys.path mutations, import hooks, poking stuff by magic
into sys.modules via well-hidden side effects in scattered __init__.py
files, ... it makes Java's rigid, wordy, explicit import scheme look very
attractive some days.  That you can't trick that into doing arbitrarily
unexpected things by magic at runtime isn't entirely a bad thing <wink>.