On 5 August 2015 at 19:01, Cameron Simpson <cs@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...
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-...
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@gmail.com | Brisbane, Australia