gh-139686: Make reloading a lazy module no-op

[QEDady]

Currently, reloading a not-yet materialized lazy module fails. This PR changes it to be a no-op. This makes sense since the reloading will happen anyway when the module is materialized e.g. by accessing an attribute.

• Issue: Reloading a lazy module that has not yet been materailized should be no-op #139686

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[brettcannon]

Minor tweaks to the tests, but otherwise LGTM!

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[QEDady]

I have made the requested changes; please review again

[QEDady]

I have made the requested changes; please review again

Also, currently the following test:

./python -m test test.test_os.test_os

fails with

test test.test_os.test_os failed -- Traceback (most recent call last):
  File "/usr/local/google/home/amere/cpython/Lib/test/test_os/test_os.py", line 1011, in test_utime_fd
    self._test_utime(set_time)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/google/home/amere/cpython/Lib/test/test_os/test_os.py", line 920, in _test_utime
    self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6)
    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 1760084197.4864256 != 1.002003 within 1e-06 delta (1760084196.4844227 difference)

because of

sys.modules['importlib.util'] = util

at the top level of the test_lazy.py. Removing the latter makes ./python -m test test_importlib fails with test_lazy failure although ./python -m test test_importlib.test_lazy works fine in all cases. That is because some other test likely reloads importlib.util. See here. Please, advise.

[bedevere-app]

Thanks for making the requested changes!

@brettcannon: please review the changes made to this pull request.

[brettcannon]

I just realized we should probably update the docs for importlib.reload to mention the new semantics.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[QEDady]

I have made the requested changes; please review again.

[bedevere-app]

Thanks for making the requested changes!

@brettcannon: please review the changes made to this pull request.

[encukou]

This “broke” buildbots :(
See the comment on the issue.

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot ARM64 macOS 3.x (tier-2) has failed when building commit dfeefbe.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/725/builds/12493) and take a look at the build logs.
4. Check if the failure is related to this commit (dfeefbe) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/725/builds/12493

Failed tests:

• test_urllib2net

Summary of the results of the build (if available):

==

Click to see traceback logs

remote: Enumerating objects: 32, done.        
remote: Counting objects:   3% (1/32)        
remote: Counting objects:   6% (2/32)        
remote: Counting objects:   9% (3/32)        
remote: Counting objects:  12% (4/32)        
remote: Counting objects:  15% (5/32)        
remote: Counting objects:  18% (6/32)        
remote: Counting objects:  21% (7/32)        
remote: Counting objects:  25% (8/32)        
remote: Counting objects:  28% (9/32)        
remote: Counting objects:  31% (10/32)        
remote: Counting objects:  34% (11/32)        
remote: Counting objects:  37% (12/32)        
remote: Counting objects:  40% (13/32)        
remote: Counting objects:  43% (14/32)        
remote: Counting objects:  46% (15/32)        
remote: Counting objects:  50% (16/32)        
remote: Counting objects:  53% (17/32)        
remote: Counting objects:  56% (18/32)        
remote: Counting objects:  59% (19/32)        
remote: Counting objects:  62% (20/32)        
remote: Counting objects:  65% (21/32)        
remote: Counting objects:  68% (22/32)        
remote: Counting objects:  71% (23/32)        
remote: Counting objects:  75% (24/32)        
remote: Counting objects:  78% (25/32)        
remote: Counting objects:  81% (26/32)        
remote: Counting objects:  84% (27/32)        
remote: Counting objects:  87% (28/32)        
remote: Counting objects:  90% (29/32)        
remote: Counting objects:  93% (30/32)        
remote: Counting objects:  96% (31/32)        
remote: Counting objects: 100% (32/32)        
remote: Counting objects: 100% (32/32), done.        
remote: Compressing objects:   7% (1/14)        
remote: Compressing objects:  14% (2/14)        
remote: Compressing objects:  21% (3/14)        
remote: Compressing objects:  28% (4/14)        
remote: Compressing objects:  35% (5/14)        
remote: Compressing objects:  42% (6/14)        
remote: Compressing objects:  50% (7/14)        
remote: Compressing objects:  57% (8/14)        
remote: Compressing objects:  64% (9/14)        
remote: Compressing objects:  71% (10/14)        
remote: Compressing objects:  78% (11/14)        
remote: Compressing objects:  85% (12/14)        
remote: Compressing objects:  92% (13/14)        
remote: Compressing objects: 100% (14/14)        
remote: Compressing objects: 100% (14/14), done.        
remote: Total 17 (delta 15), reused 4 (delta 3), pack-reused 0 (from 0)        
From https://github.com/python/cpython
 * branch                    main       -> FETCH_HEAD
Note: switching to 'dfeefbe8ead0e370cc701643d9909f84bd29f171'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at dfeefbe8ead GH-139686: Revert "gh-139686: Make reloading a lazy module no-op (GH-139857)" (#143584)
Switched to and reset branch 'main'

make: *** [buildbottest] Error 2