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)