Make types.MappingProxyType hashable
Hello Python-ideas, While answering a question earlier today, I realized that types.MappingProxyType is immutable and unhashable. It seems to me that if all values are hashable (all keys are already guaranteed to be hashable), then the mappingproxy itself should be hashable. Should I go ahead and make a patch for this, or is this a bad idea? Cheers, -Emanuel
I think you misunderstand the distinction between immutable and read-only. MappingProxyType is read-only -- you cannot modify the underlying dict through the proxy. But it's not immutable -- if the underlying dict is changed directly (e.g. by assignment to a class attribute) the proxy is changed too. So making the proxy hashable would be a mistake. What real-world use case do you have for this? On Thu, Jul 28, 2016 at 3:01 PM, Emanuel Barry <vgr255@live.ca> wrote:
Hello Python-ideas, While answering a question earlier today, I realized that types.MappingProxyType is immutable and unhashable. It seems to me that if all values are hashable (all keys are already guaranteed to be hashable), then the mappingproxy itself should be hashable. Should I go ahead and make a patch for this, or is this a bad idea?
Cheers, -Emanuel _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
From: Guido van Rossum Sent: Thursday, July 28, 2016 6:06 PM To: Emanuel Barry Cc: python-ideas@python.org Subject: Re: [Python-ideas] Make types.MappingProxyType hashable
I think you misunderstand the distinction between immutable and read-only. MappingProxyType is read-only -- you cannot modify the underlying dict through the proxy. But it's not immutable -- if the underlying dict is changed directly (e.g. by assignment to a class attribute) the proxy is changed too. So making the proxy hashable would be a mistake.
Oh, I didn't know that this was just a view over an actual dict. I guess that solves the question :)
What real-world use case do you have for this?
Not me, actually. Someone in #python asked about an immutable dict, and I pointed them towards mappingproxy, only to realize it wasn't hashable. Maybe something like frozendict could be added, though? At this point I don't really have an opinion, so it's up to the list to decide if they want it or not :) -Emanuel
On 29 July 2016 at 08:23, Emanuel Barry <vgr255@live.ca> wrote:
Not me, actually. Someone in #python asked about an immutable dict, and I pointed them towards mappingproxy, only to realize it wasn't hashable. Maybe something like frozendict could be added, though? At this point I don't really have an opinion, so it's up to the list to decide if they want it or not :)
For most cases where this kind of capability is needed, it will be sufficient to model a frozen dict as a frozen set of 2-tuples:
data = {k: str(k) for k in range(5)} data {0: '0', 1: '1', 2: '2', 3: '3', 4: '4'} frozenset(data.items()) frozenset({(4, '4'), (3, '3'), (1, '1'), (0, '0'), (2, '2')}) dict(frozenset(data.items())) {0: '0', 1: '1', 2: '2', 3: '3', 4: '4'}
The fact the frozen set is keyed by the key-value pairs rather than just the keys doesn't matter, as you can't add any new entries at all, and the same goes for any other discrepancies between the invariants of the two data structures: even though the frozen set doesn't enforce any dict invariants, their preservation is ensured by the stricter immutability and hashability invariants. And in cases where you want to expose a read-only view to a normal dictionary, then you have types.MappingProxyType. So it's not that a frozendict type couldn't be provided, it's just of highly questionable utility given other existing features. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
All right, this makes sense. Thanks for the reply! -Emanuel
From: Nick Coghlan [mailto:ncoghlan@gmail.com] Subject: Re: [Python-ideas] Make types.MappingProxyType hashable
For most cases where this kind of capability is needed, it will be sufficient to model a frozen dict as a frozen set of 2-tuples:
data = {k: str(k) for k in range(5)} data {0: '0', 1: '1', 2: '2', 3: '3', 4: '4'} frozenset(data.items()) frozenset({(4, '4'), (3, '3'), (1, '1'), (0, '0'), (2, '2')}) dict(frozenset(data.items())) {0: '0', 1: '1', 2: '2', 3: '3', 4: '4'}
The fact the frozen set is keyed by the key-value pairs rather than just the keys doesn't matter, as you can't add any new entries at all, and the same goes for any other discrepancies between the invariants of the two data structures: even though the frozen set doesn't enforce any dict invariants, their preservation is ensured by the stricter immutability and hashability invariants.
And in cases where you want to expose a read-only view to a normal dictionary, then you have types.MappingProxyType.
So it's not that a frozendict type couldn't be provided, it's just of highly questionable utility given other existing features.
Cheers, Nick.
2016-07-29 0:06 GMT+02:00 Guido van Rossum <guido@python.org>:
I think you misunderstand the distinction between immutable and read-only. MappingProxyType is read-only -- you cannot modify the underlying dict through the proxy. But it's not immutable -- if the underlying dict is changed directly (e.g. by assignment to a class attribute) the proxy is changed too.
Oh right. That's why I'm not a big fan of MappingProxyType :-) -- It reminds me that I wrote a frozendict PEP which was rejected :-) https://www.python.org/dev/peps/pep-0416/ Victor
Good idea. Victor Le 29 juil. 2016 12:01 AM, "Emanuel Barry" <vgr255@live.ca> a écrit :
Hello Python-ideas, While answering a question earlier today, I realized that types.MappingProxyType is immutable and unhashable. It seems to me that if all values are hashable (all keys are already guaranteed to be hashable), then the mappingproxy itself should be hashable. Should I go ahead and make a patch for this, or is this a bad idea?
Cheers, -Emanuel _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (4)
-
Emanuel Barry -
Guido van Rossum -
Nick Coghlan -
Victor Stinner