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, martin.panter, ncoghlan, wolma
Date 2016-07-13.01:34:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1468373679.94.0.910012510401.issue27487@psf.upfronthosting.co.za>
In-reply-to
Content
Breaking down a few of the moving parts here:

* Yes, modules replacing themselves in sys.modules as a side effect of import is supported behaviour (it's why the import system looks them up by name in sys.modules as the final step, rather than just returning whatever the loader returns)

* the dependency on __spec__ attributes is actually in importlib, where following PEP 351 Brett has been pushing hard to ensure modules always have a __spec__ attribute so the rest of the import system (including, indirectly, runpy) can rely on having it available (however, as seen here, not everything in sys.modules is going to be a module, so we may need to either keep more of the workarounds that help tolerate folks breaking that assumption, or else find a way to try to enforce it even for custom objects)

* explicitly copying __spec__ from the original module object to the replacement object (in Wolfgang's code) should indeed be enough to get the use case reported here restored to the way it behaved in 3.5.1
History
Date User Action Args
2016-07-13 01:34:39ncoghlansetrecipients: + ncoghlan, brett.cannon, eric.snow, martin.panter, wolma
2016-07-13 01:34:39ncoghlansetmessageid: <1468373679.94.0.910012510401.issue27487@psf.upfronthosting.co.za>
2016-07-13 01:34:39ncoghlanlinkissue27487 messages
2016-07-13 01:34:39ncoghlancreate