May be the following simple prototype of frozendict could be useful? def frozen_error(): return RuntimeError("frozendict is not mutable") class frozendict(dict): # def __setitem__(self, key, val): raise frozen_error() # def setdefault(self, key, val=None): raise frozen_error() # def update(self, ob): raise frozen_error() # def pop(self): raise frozen_error() # def popitem(self, ob): raise frozen_error() # def clear(self, ob): raise frozen_error() # def __delitem__(self, key): raise frozen_error() # def __repr__(self): return "frozendict(" + dict.__repr__(self)[1:-1] + ")" # def __str__(self): return "frozendict(" + dict.__str__(self)[1:-1] + ")" # def fromkeys(self, keys, val=None): return frozendict([(key,val) for key in keys]) # def copy(self): return frozendict(self.items()) среда, 10 октября 2018 г., 20:06:03 UTC+3 пользователь Philip Martin написал:
Hi, I first want to thank everyone in the community for the contributions over the years. I know the idea of a frozendict has been proposed before and rejected. I have a use case for a frozendict implementation that to my knowledge was not discussed during previous debates. My reasoning for a frozendict class stems from patterns I typically see arise when performing ETL or data integrations and conversions. I generally have used MappingProxyType as a way to set default mapping to a function or to set an empty mapping to a function. I've created a gist with an example use case:
https://gist.github.com/pmart123/493edf84d9aa61691ca7321325ebb6ab
I've included an example of what code typically looks like when using MappingProxyType and what it could look like with a frozendict implementation. I believe this use case may also be under-reported in open source code as it often crops up when integrating third-party data sources, which at times can't be open sourced due to licensing issues. I would love to hear if anyone has used MappingProxyType in a similar manner, or if this use case could help warrant a frozendict in the standard library.