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

[Eric Snow]

On Thu, Nov 24, 2011 at 7:45 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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)

That's good.  I'm putting together a comprehensive  reference on
imports in Python and plan on having a section that emphasizes the
difference between scripts and modules.  I think a lot of people (not
just beginners) don't recognize it.  This discussion is helping with
that section.  :)

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

Yeah, and I like where you're going with Issue13475.  I still have a
concern with the implicit "-p .", but I'll take it up on the tracker.

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

Well, if you factor in a -p flag, is it as big a deal?

-eric

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