On Sat, Apr 9, 2022 at 1:53 PM dfremont--- via Python-Dev < python-dev@python.org> wrote:
> Thanks, Brett. I understand why the behavior happens, I just don't > understand the decision to implement imports this way. Since there's no > warning in the documentation that removing items from sys.modules can break > the fact that "import X.Y" defines "X.Y" (note that the "behind the > curtain" stuff happens *before* the second import, so it's still the case > that the second import does not define "X.Y" as implied by the docs), and > there's also no warning that submodules must be removed at the same time as > their parent, I would expect my example code to work. > > I don't see any downside to having "import X.Y" always set the Y attribute > of X (instead of only setting it if 'X.Y' is not already in sys.modules), > but if you think it's a bad idea, here's a suggestion for a paragraph to > add at the end of PLR 5.4.2: > > "Note that the binding to the submodule object in the parent module's > namespace is only added when the submodule is actually *loaded*. If the > submodule is already present in `sys.modules` when it is imported (through > any of the mechanisms above), then it will not be loaded again and no > binding will be added to the parent module." > I don't want the import docs to be that detailed. As others have suggested, something more about "directly mutating the contents of `sys.modules` may have unexpected side-effects" is better. > > If removing a module but not its submodules from sys.modules is considered > "cheating" and could potentially break other parts of the import system, > that should also be documented, e.g. by adding the sentence "If you delete > a key for a module in `sys.modules`, you must also delete the keys for all > submodules of that module." at the end of the 3rd paragraph of PLR 5.3.1. > However, I would much rather not impose this restriction, since it seems > unnecessarily restrictive (indeed, my code violates it but works fine, and > changing it to transitively remove all submodules would necessitate > reloading many modules which do not actually need to be reloaded). > > (Terry, thanks for your suggestion. My concern about adding such a vague > warning is that to me, it reads as saying that all bets are off if you > modify sys.modules by hand, which means it would never be safe to do so, > i.e., the behavior might change arbitrarily in a future Python version. That's correct, and that's the reason Terry suggested that wording. If we were to do the import system over again, sys.modules would either be hidden from direct access, be attached to the code implementing the importer, or have a leading underscore. So we don't want to strengthen the definition at all; best we are comfortable with is put up a warning that you don't want to do stuff with sys.modules unless you know what you're doing. > But in my opinion there are legitimate cases where it is necessary to > ensure a module will be reloaded the next time it is imported, and the > documented way to do that is to remove entries from sys.modules.) > The Python import system is simply not designed around the idea of undoing an import (the fact that imports have side-effects guarantee it will never be 100% successful). Plus even using something like importlib.reload() won't necessarily get you what you want since any object stored as an attribute somewhere will not get updated.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MLQT5UTTRDNXP5PTTIAAJME6JBAWASBR/ Code of Conduct: http://python.org/psf/codeofconduct/
