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

[Nick Coghlan]

On Fri, Nov 25, 2011 at 6:32 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>  So the behavior of Python execution can be grouped thusly:
>  - scripts (<script>, -m, -, -c, interactive interpreter) [1]
>  - modules (import,)
>  - execs (exec, eval, execfile, input)

Yeah, that's basically accurate, although I'd describe it as:

- the main module (includes sys.path[0] initialisation, sys.argv
initialisation, messes with "__name__", may not be importable
- imported modules (must meet the import system's definition of a
"valid module", which can be altered by various import hooks)
- source execution (exec/eval/literal_eval)

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

Being useful is more important than being consistent per se. With
zipfiles and directory execution, for example, their __main__.py file
gets executed, but sys.path[0] is set to the zipfile or directory.

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

-m has to do *something* with sys.path or it doesn't work for files
you're working on in the current directory (unless that directory is
already on sys.path). For example, I mostly leave my working directory
sitting at the "src" directory in my checkout, then use '-m' to run
various things from within the Python package in that directory.

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

Nope, it would just make it a backwards compatibility nightmare. It's
already skating on thin ice in a couple of places by having to make
the argument that it's taking things that are technically *already*
broken (often in somewhat obscure ways) and turning them into explicit
exceptions that should make the underlying problem clearer :)

Cheers,
Nick.

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