Change extracted from the larger #292 change.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (bbca44b) to head (b099527).

@@            Coverage Diff            @@
##            master      #294   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            4         4           
  Lines          535       534    -1     
  Branches       100       100           
=========================================
- Hits           535       534    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

What's the benefit?
The MappingProxyType downsides given in PEP 814 doesn't really apply to this internal mapping:

This type is not hashable and it’s not possible to inherit from it. It’s also easy to retrieve the original dictionary which can be mutated, for example using gc.get_referents().

It avoids import types which can improve the tomli startup time a little bit.

Accessing frozendict items is also a little bit faster than MappingProxyType: Mean +- std dev: [proxy] 20.0 ns +- 0.4 ns -> [frozendict] 18.1 ns +- 0.4 ns: 1.10x faster. (I'm surprised that the difference is not higher.)

python3.15 -m pyperf timeit -s 'import types; d={"key": 1}; d=types.MappingProxyType(d)' 'd["key"]' -o proxy.json
python3.15 -m pyperf timeit -s 'd={"key": 1}; d=frozendict(d)' 'd["key"]' -o frozendict.json

I don't think this does much anything currently because tomli._re imports re and functools which both bring types in regardless. If we lazy import tomli._re though then this makes sense, I think.

Ok, I close my PR.

If we lazy import tomli._re though then this makes sense, I think.

Since the tomli._re lazy import has been merged, is it worth re-opening this PR to avoid import types as well?

I'd imagine that the attempt to avoid types import still remains futile, seeing that the new lazy import mechanism uses types.LazyImportType lazy objects.

If CPython wants this change, however, I don't object to it. A frozendict better reflects the kind of type that was needed here, i.e. an immutable mapping rather than a read-only proxy to a mutable mapping.

Ok, I recreated my PR to use frozendict: #297.

the new lazy import mechanism uses types.LazyImportType lazy objects.

CPython doesn't import types for lazy imports (AFAIK); that's just where the type is exposed to Python code.