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:
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.