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

[Eric Snow]

On Thu, Nov 24, 2011 at 4:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.

<faceplam />

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

 So the behavior of Python execution can be grouped thusly:
  - scripts (<script>, -m, -, -c, interactive interpreter) [1]
  - modules (import,)
  - execs (exec, eval, execfile, input)

and we want the sys.path initialization to be consistent across all
script-like execution?

Either that's not the case, or the "-m" flag is in its own group, or
PEP 395 is trying to do something it shouldn't.  I'd argue it's the
first, and that sys,path initialization should apply only to the
interactive interpreter (and -c).  Is the consistency worth the
trouble?  Maybe so.  Maybe not.

Doesn't restricting the application of sys.path initialization make
PEP 395 simpler?

[1]  as indicated by __name__ == "__main__", for better or worse

> (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)

Maybe a premature optimization of sorts?

> Regardless, your question did just make me realise that my current
> proposal for new -m semantics in PEP 395 is broken.

Glad I could be of _some_ kind of help. <wink>

-eric

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