GeezerVison

If we're covering all the bases:

Here, key can be an arbitrary object as well.

Also, the iteration should have a critical section around it -- see PyDict_Next docs.

But perhaps the best way to solve that would be switching to always use frozendict with string keys, so let's leave this to a future PR?

Also, the iteration should have a critical section around it -- see PyDict_Next docs.

I think that adding a critical section here is best for a future PR. This PR is more about fixing a mutation during repr. In contrast, adding a critical section is intended for the free-threaded build. Additionally, I realized that there are quite a few other times in this file where PyDict_Next is called without a critical section, so a new PR is needed anyway. I can create an issue for this change, although, should we wait on a PR until this one is merged to avoid any conflicts? I'm fine adding a critical section now, though, if you think that is better.

But perhaps the best way to solve that would be switching to always use frozendict with string keys, so let's leave this to a future PR?

I agree, enforcing that kw has only string keys seems like the best solution. Just to make sure I understand correctly, when you mean switch to using a frozendict, are you saying that the kw entry in the partialobject struct should be a frozendict instead of a dict, or are you referring to something only in this function (partial_repr)? If the former, I would like to work on making that change in a new PR. I’m fairly new to CPython, so I’d appreciate any suggestions you have for that change.

I think that adding a critical section here is best for a future PR.

OK!

are you saying that the kw entry in the partialobject struct should be a frozendict instead of a dict, or are you referring to something only in this function (partial_repr)?

The former seems worth looking into. As you said, there's a lot of PyDict_Next without critical sections (and other possibilities for possible mutation than threads); frozendict could solve these neatly.

I can create an issue for this change, although, should we wait on a PR until this one is merged to avoid any conflicts?

Yes.