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 -- seePyDict_Next docs.

But perhaps the best way to solve that would be switching to always usefrozendict 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 duringrepr. 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 wherePyDict_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.

The one change we could make now is to replaceint i withPy_ssize_t pos as this would make this loop consistent with the docs and other calls toPyDict_Next.

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 thatkw has only string keys seems like the best solution. Just to make sure I understand correctly, when you mean switch to using afrozendict, are you saying that thekw entry in thepartialobject struct should be afrozendict instead of adict, 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 ofPyDict_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.