gh-124397: Add pure Python implementation of threading.iter_locked

[eendebakpt]

Add a Python implementation of iter_locked.

Continuation of #133908 and #133272. The name was discussed in discuss.python.org

Since this is now a pure python implementation, we could also consider adding this to packages such as https://github.com/facebookincubator/ft_utils or https://github.com/dpdani/cereggii

• Issue: Strategy for Iterators in Free Threading #124397

---

📚 Documentation preview 📚: https://cpython-previews--138261.org.readthedocs.build/

[picnixz]

I would have really preferred something like threading.iterate to mimick the way we name things, e.g., enumerate[this], iter[over that], filter[this], map[it], etc (all of them are verbs), but I see why it's named iter_locked to mimick iter, though it looks like a variable name to me rather than a function name. My rationale for not having locked inside the name is that it belongs to the threading module, and thus semantically should be used by something that is threading-related, but this is probably too many guesses

[ZeroIntensity]

I'm still not a huge fan of putting this in threading. threading should be for synchronization primitives, but this is a utility.

[eendebakpt]

Just an idea: what about using the builtin iter with a new keyword locked? For locked=False we have the normal behavior, for True we use the iter_locked defined here.

[ZeroIntensity]

I like that idea, but it would require a lot more work to accomplish. Changes to builtins require PEPs.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[eendebakpt]

#148894 is a more complete implementation, closing this PR

[vstinner]

#148894 is a more complete implementation, closing this PR

You didn't close the PR. I suppose that it was a mistake, so I close the PR.