@brettcannon I started working on this one, but I encountered the following issues:
If we remove load_module, can we just assume that exec_module exists and implements the expected protocol? (namely, what to do in term of ABCs & co?)
There are a lot of tests that only rely on load_module but do not rely on exec_module. There are tests for exec_module though but it's mainly tested via load_module() calls.
Should we keep testing load_module() implementations based on exec_module, or should we change the test suite so that we only use exec_module? or should we just keep the load_module() implementation but for tests only.
It's kind of hard to know what happens in both tests and importlib at the same time as there are many mixins and dynamically-set attributes. I tried to replace the load_module() with an exec_module() equivalent but it's not easy.
If we remove load_module, can we just assume that exec_module exists and implements the expected protocol? (namely, what to do in term of ABCs & co?)
The ABCs where this would matter should already require exec_module().
There are a lot of tests that only rely on load_module but do not rely on exec_module. There are tests for exec_module though but it's mainly tested via load_module() calls.
The tests should probably go, but checking that appropriate tests have a matching exec_module() test would be good.
Should we keep testing load_module() implementations based on exec_module, or should we change the test suite so that we only use exec_module? or should we just keep the load_module() implementation but for tests only.
Only use exec_module(); load_module() shouldn't be in the code base at the end.
It's kind of hard to know what happens in both tests and importlib at the same time as there are many mixins and dynamically-set attributes.
Yep. It's very much going to be a "delete the methods and fix the failures" kind of PR. It could be done in pieces if you deleted the method in one place, fixed some tests, and reverted the deletion before opening the PR. That way all you're doing is removing future-redundant tests or fixing them.
Activity
picnixz commented on May 11, 2025
picnixz commented on May 11, 2025
picnixz commented on May 11, 2025
@brettcannon I started working on this one, but I encountered the following issues:
It's kind of hard to know what happens in both tests and importlib at the same time as there are many mixins and dynamically-set attributes. I tried to replace the load_module() with an exec_module() equivalent but it's not easy.
brettcannon commented on Aug 8, 2025
The ABCs where this would matter should already require exec_module().
The tests should probably go, but checking that appropriate tests have a matching exec_module() test would be good.
Only use exec_module(); load_module() shouldn't be in the code base at the end.
Yep. It's very much going to be a "delete the methods and fix the failures" kind of PR. It could be done in pieces if you deleted the method in one place, fixed some tests, and reverted the deletion before opening the PR. That way all you're doing is removing future-redundant tests or fixing them.
FFY00 commented on Feb 25, 2026
I don't think there are any usages of load_module in the import machinery anymore, just in the tests.