GeezerVison

@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?

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.

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.

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.

This change fix the following example:

fd = None

class SpecialDict(frozendict):
    def __new__(self):
        global fd
        fd = frozendict(x=1)
        return fd

print(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.

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

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