[Import-SIG] Updated PEP 395 ("Qualified Names for Modules" aka "Implicit Relative Imports Must Die!")
ncoghlan at gmail.com
Fri Nov 25 03:45:20 CET 2011
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) 
> - modules (import,)
> - execs (exec, eval, execfile, input)
Yeah, that's basically accurate, although I'd describe it as:
- the main module (includes sys.path 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 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 :)
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIG