gh-141510: Optimize {frozen}dict.fromkeys for frozendict

[corona10]

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

[methane]

If d is a newly created object, whether it's a dict or a frozendict, wouldn't it be unnecessary to lock it?

If we consider the possibility that d might leak to another thread for some reason, wouldn't it be necessary to lock it even in the case of a frozendict?

classD(frozendict):
def__new__(cls):
returnfrozendict({"a":1, "b":2})
d=D.fromkeys("def")
print(d)
# frozendict({'a': 1, 'b': 2, 'd': None, 'e': None, 'f': None})

In this case, d is exact frozendict, but d can be leaked to other thread.

[corona10]

I think we could remove the lock for d, but since it has been locked before, would it make sense to test this in a separate PR?

[vstinner]

I don't think that other threads can access d during fromkeys() call.

D.fromkeys() calls dict.fromkeys() and dict.__new__(): the return type is dict, not D.

[methane]

D.fromkeys() calls dict.fromkeys() and dict.__new__(): the return type is dict, not D.

dict.fromkeys() is classmethod. D.fromkeys() calls dict.fromkeys(D).

Here's an even worse example.

d0=NoneclassD(frozendict):
def__new__(cls):
globald0d0=frozendict({"a":1, "b":2})
returnd0d=D.fromkeys("def")
print(d0) # frozendict({'a': 1, 'b': 2, 'd': None, 'e': None, 'f': None})print(d) # frozendict({'a': 1, 'b': 2, 'd': None, 'e': None, 'f': None})

In this case d0 is mutated after it is exposed to Python.
It completely betrays the expectations of a frozendict.

[vstinner]

Oh. This is bad :-( I wrote #144944 to raise an exception if this case occurs.

[corona10]

@vstinner@methane I've simplifed the PR to follow your last reivews.

[corona10]

@vstinner@methane
It turns out that removing the lock from d requires quite a bit of cleanup, since there is a series of internal lock-holding checks. I’ll handle this separately in a follow-up change.

[vstinner]

LGTM