This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients brett.cannon, eric.snow, ncoghlan, serhiy.storchaka, vstinner
Date 2017-07-26.14:45:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1501080335.32.0.66947337459.issue31038@psf.upfronthosting.co.za>
In-reply-to
Content
This is a result of a known quirk in the way sys.path entry execution works: the search for "__main__.py" isn't constrained specifically to sys.path[0].

That's almost entirely a bad thing, but I'd been ignoring it because I hadn't thought of a nice way of fixing it that didn't require some substantial changes to the import system APIs.

However, it just occurred to me that I may have been overcomplicating matters: we don't need to keep runpy from *finding* a __main__.py from outside sys.path[0] in this case, we just need to keep it from *running* it.

That means that after we find the candidate module spec for __main__, we can introduce a new constraint:

    if os.path.commonpath([sys.path[0], spec.origin]) != sys.path[0]:
        raise RuntimeError(...)

It might still be a little fiddly to decide exactly when to enforce the constraint, but it should still be much easier than attempting to constrain the search for the spec directly.
History
Date User Action Args
2017-07-26 14:45:35ncoghlansetrecipients: + ncoghlan, brett.cannon, vstinner, eric.snow, serhiy.storchaka
2017-07-26 14:45:35ncoghlansetmessageid: <1501080335.32.0.66947337459.issue31038@psf.upfronthosting.co.za>
2017-07-26 14:45:35ncoghlanlinkissue31038 messages
2017-07-26 14:45:35ncoghlancreate