cc @encukou since you originally suggested this change.

Most of the test errors are due to problems with pickling the partial object, due to the fact that frozendict does not work for all protocols. I'm not sure what the best approach is, but one solution might be to define __reduce_ex__ for partial and have it create a temporary dict for certain protocols instead of using a frozendict.

Update: I realized that the simplest solution would be for partial_reduce to return a dict instead of a frozendict as there were issues pickling a frozendict. However, that meant I had to introduce a partial_copy function for shallow copies. I left the pure python implementation as is, which means it uses __reduce_ex__, however I am open to changing this to be consistent with the C code.

Sorry for the delay.

Seeing the PR, I realized it's a backwards incompatible change, since keywords is publicly accessible:

>>> import functools
>>> p = functools.partial(print)
>>> p.keywords['sep'] = '::'
>>> p('a', 'b')
a::b

It would be good to deprecate this first, but that looks like a lot of extra work :/

@vstinner, do you know of more cases where it would be good to replace dict with frozendict with a deprecation period? Would it be worth it to create a helper for this?

@vstinner, do you know of more cases where it would be good to replace dict with frozendict with a deprecation period? Would it be worth it to create a helper for this?

How would you implement such deprecation period? In the documentation only?

There are many dictionaries in the stdlib which should not be modified but are declared as mutable dict (dict type). Changing these dictionaries to frozendict would be nice to make the API stricter. But I didn't propose such changes since it can affect projects expecting a mutable dictionary.

So far, if I recall correctly, only two changes (gh-144909 and gh-144910) were merged to replace dict with frozendict in private stdlib APIs. I was told that the _opcode_metadata change (private module) impacts Meta CinderX which does modify _opcode_metadata dictonaries on purpose (they wrote a simple change to become compatible with Python 3.15 frozendict).

There is also gh-144904 which replaced types.MappingProxyType with frozendict. It changed the dataclasses and email.headerregistry APIs in subtle way (return MappingProxyType instead of frozendict, it's documented).

Another example is gh-144906 which proposed converting errno.errorcode dict to a frozendict. The PR was rejected by the module maintainer, since it's useful to be able to modify errno.errorcode dictionary.

By the way, the SC decision includes:

Stdlib adoption should happen with each module maintainer’s approval, not as a mechanical sweep.

How would you implement such deprecation period? In the documentation only?

I was thinking of a new mapping class that warns when mutated.

Stdlib adoption should happen with each module maintainer’s approval, not as a mechanical sweep.

Yes, but when approval is given, we need to honor the backwards compatibility policy.

Seeing the PR, I realized it's a backwards incompatible change, since keywords is publicly accessible

Okay, I will defer to your judgment on whatever makes the most sense.

Additionally, this PR also enforces that the keywords for the keywords dictionary are always strings. This is also a backward-incompatible change, but it might be easier to implement than converting the keywords dict to a frozendict.

Additionally, this PR also enforces that the keywords for the keywords dictionary are always strings.

Yeah, but since you can't call functions with non-string keywords, I see this as erroring out earlier.

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

@encukou do you think it is still worth deprecating this feature?

That depends -- mainly on how many other cases would use the deprecation. It's probably not worth the trouble for this case only.

Okay, I'll close this then