Do you have any use case for adding it?
We already have a set and frozenset pair, and we have dict. It is symmetrical to add &PyFrozenDict_Type alongside &PyDict_Type, but do you think it would be useful?
I’m just wondering.
1 Like
Presumably if we have APIs that only accept an instance of a frozen dict, then it needs to be available as an argument type. I’d expect some[1] of those APIs are going to be part of frozendict itself (to accept self).
This isn’t really a “should” question - if it’s needed, and I think it is, it’ll be done. If it’s not needed, why would we?
Hedging here, I really expect all of those APIs to be part of
frozendict, and everywhere else we won’t be so strict. Functions expecting dict-like objects will have to be relaxed to accept “things that behave like mappings”. ↩︎
Note that neither set, nor frozenset converters are used in the current code (except tests for converters). The tuple, list and dict converters are used a dozen or two times each.
It is likely that we will need to replace some occurrences of the dict converter with the converter that accepts dict and frozendict. But the current syntax just does not support this, and there is no way to extend it. So it will likely be replaced with a simple object converter and an explicit check in the code. It was just a syntax sugar.
2 Likes