gh-125245: Fix race condition when importing collections.abc

[colesbury]

If multiple threads concurrently imported collections.abc, some of the threads might incorrectly see the "shim" Lib/collections/abc.py module instead of the correct Lib/_collections_abc.py module. This was observed in the free threading build, but could, in theory, occur in the default GIL-enabled build as well.

• Issue: Race condition when importing collections.abc #125245

[colesbury]

This strategy won't work for decimal / _pydecimal. I'm not sure how to handle that, but I'm less concerned about that case because in normal circumstances decimal uses the C _decimal module instead.

[colesbury]

cc @davidhewitt @ngoldbaum

[serhiy-storchaka]

LGTM.

The side effect is that user no longer needs to import collections.abc explicitly if they imported collections. It will be hard to change this back because users will write code that depends on this. Is it fine? cc @rhettinger

[ngoldbaum]

I applied this patch onto the 3.13 branch and I'm no longer able to reproduce the error I reported in #125245 by running the PyO3 tests repeatedly.

[Yhg1s]

We have other modules that do this (e.g. multiprocessing.context, not to mention the weird case of os.path). Using modules in packages without explicitly importing them is a bigger problem, because something else might have imported it for you. I think for collections.abc I think it's fine for collections to do the importing. It's a special case anyway because they're effectively builtin types and collections is already importing the module anyway, just not the shim. In the unlikely event we really want to decouple collections.abc from collections (which requires that collections not use anything from collections.abc, which seems extremely unlikely), we can always use __getattr__ in collections to load it lazily.

[miss-islington-app]

Thanks @colesbury for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[bedevere-app]

GH-125944 is a backport of this pull request to the 3.13 branch.