Description

picnixz

opened on May 11, 2025

Issue body actions

Feature or enhancement

Originally deprecated in #23469, later delayed to 3.15 in aa81a6f.

Activity

1. picnixz

   added

   type-featureA feature request or enhancementA feature request or enhancement

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   topic-importlib

   on May 11, 2025
2. picnixz

   self-assigned this

   on May 11, 2025
3. picnixz commented on May 11, 2025

   

   picnixz

   on May 11, 2025 · Hidden as outdated

   Author

   show commentMore actions
4. picnixz

   closed this as a duplicateof Meta issue for cleaning up import system cruft #97850 on May 11, 2025
5. picnixz commented on May 11, 2025

   

   picnixz

   on May 11, 2025 · Hidden as resolved

   Author

   show commentMore actions
6. picnixz

   reopened this on May 11, 2025
7. picnixz commented on May 11, 2025

   

   picnixz

   on May 11, 2025

   MemberAuthor

   More actions

   @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.
8. picnixz

   removed their assignment

   on Jul 13, 2025
9. brettcannon commented on Aug 8, 2025

   

   brettcannon

   on Aug 8, 2025

   Member

   More actions

   • 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.
10. FFY00 commented on Feb 25, 2026

    

    FFY00

    on Feb 25, 2026

    Member

    More actions

    I don't think there are any usages of load_module in the import machinery anymore, just in the tests.

    Reacted by Brett Cannon

Issue actions