My preference is (1), revert. You have to understand how sys.modules works before you can change it, and if you waste time debugging your mistake, so be it. I think the sys.py proposal is the wrong way to fix the mistake you made there. On Wed, Sep 13, 2017 at 4:00 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Tue, Sep 12, 2017 at 9:30 PM, Guido van Rossum <guido@python.org> wrote:
I find this a disturbing trend.
Which trend? Moving away from "consenting adults"? In the case of sys.modules, the problem is that assigning a bogus value (e.g. []) can cause the interpreter to crash. It wasn't a problem until recently when I removed PyInterpreterState.modules and made sys.modules authoritative (see https://bugs.python.org/issue28411). The options there are:
1. revert that change (which means assigning to sys.modules deceptively does nothing) 2. raise an exception in all the places that expect sys.modules to be a mapping (far from where sys.modules was re-assigned) 3. raise an exception if you try to set sys.modules to a non-mapping 4. let a bogus sys.modules break the interpreter (basically, tell people "don't do that")
My preference is #3 (obviously), but it sounds like you'd rather not.
I think we have bigger fish to fry and this sounds like it could slow down startup.
It should have little impact on startup. The difference is the cost of importing the new sys module (which we could easily freeze to reduce the cost). That cost would apply only to programs that currently import sys. Everything in the stdlib would be updated to use _sys directly.
If you think it isn't worth it then I'll let it go. I brought it up because I consider it a cheap, practical solution to the problem I ran into. Thanks!
-eric
-- --Guido van Rossum (python.org/~guido)