[Import-SIG] Updated PEP 395 ("Qualified Names for Modules" aka "Implicit Relative Imports Must Die!")

[Nick Coghlan]

On Thu, Nov 24, 2011 at 8:38 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> So, at this point, is it just an artifact of early Python, when better
> solutions weren't around yet?  What am I missing here?

sys.path[0] initialisation is essential for making the interactive
interpreter useful - when you're developing new Python code, you want
to be able to import whatever you're working on into an interactive
session without having to mess about with sys.path[0] manually.

The rest pretty much than follows from a desire to maintain some level
of consistency with the interactive prompt behaviour.

(I don't know Guido's original reasoning though - the current
behaviour was well established long before I started using the
language. As far as I know, it's been this way since the earliest
public releases)

Regardless, your question did just make me realise that my current
proposal for new -m semantics in PEP 395 is broken. It assumes that
the module is going to be found in a subdirectory of the current
directory and that's just plain wrong (e.g. for cases like "python -m
timeit"). However, fixing it is pretty easy, and addresses a slight
concern I had with what it allowed (i.e. the "python -m
tests.test_foo" and "python -m test_foo" cases).

The solution is simply to *not* adjust modname in the "-m" case (i.e.
keep the initialisation completely consistent with the interactive
prompt and -c, as it is now). Then the effect of PEP 395 will just be
to allow "python -m packages.tests.test_foo" to work from anywhere
within the package hierarchy, *without* allowing the abbreviated
forms. That's a much better, more consistent outcome.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia