Nick Coghlan added the comment:
Since reload re-uses the existing namespace, having two names is less messy
when they're just aliases for the same module object (it still has all the
usual cache validity problems of any reload operation, but it doesn't have the
extra challenges of two different module objects derived from the same source
code).
As such, with -m, adding:
import __main__
sys.modules[__main__.__spec__.name] = __main__
is sufficient to get this working again, and will work for any of the PEP 451
based versions (i.e. 3.4+). (I'm open to an RFE to get runpy to do this by
default in 3.7+ - it's an idea that has come up several times, and I think it
will ultimately be less surprising than the current behaviour of allowing two
entirely distinct copies of the module to be loaded)
The direct execution case is a bit different, as that's genuinely missing a
__spec__ entry, and needs to be told how to reload itself:
import __main__
main_file = __main__.__file__
main_name = os.path.splitext(os.path.basename(main_file))[0]
__main__.__spec__ = importlib.util.spec_from_file_location(main_name,
main_file)
sys.modules[__main__.__spec__.name] = __main__
The two cases can be distinguished at runtime by whether or not
__main__.__spec__ was already set.
Since this isn't really something we encourage people to do in general, but
does remain possible for frameworks that want to support live reloading of
__main__, I'm OK with requiring that extra framework-provided scaffolding in
3.4+.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29206>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
