[Python-ideas] proposal: "python -m foo" should bind sys.modules['foo']

[Nick Coghlan]

On 5 August 2015 at 19:01, Cameron Simpson <cs at zip.com.au> wrote:
> Ah, ok, many thanks. I've now read this, particularly this section:
>
> http://legacy.python.org/dev/peps/pep-0395/#fixing-pickling-without-breaking-introspection
>
> I see that Guido has lent Nick the time machine, as that section outlines a
> scheme almost word for word what I propose. Though not quite.
>
> I see that this was withdrawn, and I after reading the whole PEP and the
> withdrawal statement at the top I think there are two probalems with the
> PEP. One is that, as stated, several of these issues have since been
> addressed elsewhere (though not my issue). The other is that it tried to
> address a whole host of issues which are related more by sharing the import
> system than necessarily being closely related of themselves, though clearly
> there are several scenarios that need considering to ensure that one fix
> doesn't make other things worse.

Right, the withdrawal was of that *specific* PEP, since it hadn't aged
well, and covered various things that could be tackled independently.

> I still wish to put forth my proposal on its own, probably PEPed, for the
> following reasons:
>
> (a) at present the multiple import via __main__/"python -m" is still not
> fixed
>
> (b) that the fix here:
>
> http://legacy.python.org/dev/peps/pep-0395/#fixing-dual-imports-of-the-main-module
>
> seems more oriented around keeping sys.path sane than directly avoiding a
> dual import
>
> (c) my suggestion both reuses __qualname__ proposal almost as PEP495
> suggested
>
> (d) can't break anything because modules do not presently have a
> __qualname__

>From an *implementation* perspective, you'll want to look at Eric's
own PEP 451: https://www.python.org/dev/peps/pep-0451/

While I mentioned it in relation to pickle compatibility in the PEP
395 withdrawal notice, it's also relevant to reducing the risk of
falling into the double import trap.

In particular, __spec__.name already holds the additional state we
need to fix this behaviour (i.e. the original module name), I just
haven't found the opportunity to go back and update runpy to take
advantage of PEP 451 to address this and other limitations.

It would definitely be good to have a PEP addressing that.

Cheers,
Nick.

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