[Import-SIG] Updated PEP 395 ("Qualified Names for Modules" aka "Implicit Relative Imports Must Die!")
ncoghlan at gmail.com
Thu Nov 24 12:33:15 CET 2011
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 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 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
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.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIG