gh-141510: Add frozendict_check_mutable()

[vstinner]

frozendict.fromkeys() now checks if it can mutate the newly created frozendict.

• Issue: PEP 814: Add built-in frozendict type #141510

[vstinner]

@methane@corona10: I wrote this change to raise an exception if a frozendict subclass constructor keeps a reference to the newly created dictionary.

I don't know which error message should be used, so I wrote: RuntimeError("cannot mutate frozendict already exposed in Python"). Do you have a better error message to propose?

[markshannon]

Frozen dicts are immutable, that's the whole point of them, so why are we allowing them to be mutated?

Mutation of tuples has been an endless source of bugs, please don't do the same with frozen dicts.

[markshannon]

I don't know which error message should be used, so I wrote: RuntimeError("cannot mutate frozendict already exposed in Python"). Do you have a better error message to propose?

This should be a SystemError.

[corona10]

Frozen dicts are immutable, that's the whole point of them, so why are we allowing them to be mutated?

I concur with Mark's opinion here.

[corona10]

IIRC, Checking Py_REFCNT at runtime is not thread safe at free-threaded build.

[vstinner]

This change fix the following example:

fd=NoneclassSpecialDict(frozendict):
def__new__(self):
globalfdfd=frozendict(x=1)
returnfdprint(SpecialDict.fromkeys("y"))

Currently, _PyDict_FromKeys() calls SpecialDict.__new__() which runs arbitrary Python code.

This change detects the special constructor and raises an error.

Mutation of tuples has been an endless source of bugs, please don't do the same with frozen dicts.

An alternative is to modify _PyDict_FromKeys() to not call the subclass constructor, but always call frozendict constructor: I wrote #144947 to implement this idea.

A more radical fix would be to disallow subclassing frozendict.

[vstinner]

frozendict_check_mutable() was a bad idea, I close the PR.

I wrote a 3rd PR to fix fromkeys(): #144952 copies the frozendict.