frozendict (was: Possible patch for functools partial...)
So I'm thinking either we make an immutable/hashable dict while we're at it, or store the keyword arguments as a tuple (which guarantees immutability), and only convert them back to a dict when you want to call the partial object (simpler, slower).
I'd support an immutable dict. [...]
I've set out to implement a frozendict (like frozenset) for use to store functools.keywords' attribute, and quickly realized I didn't think of an obvious flaw in that idea. A frozenset will only accept hashable members, but a frozendict can't afford this luxury for its values. I'm not sure how should I go about handling that, if at all. Should I implement a frozendict which will remain unhashable but support equality testing like a regular dict? A frozendict that is only hashable if all its values are hashable, like a tuple? Is the whole notion of a frozendict worthy, given this limitation? I'd be happy to hear python-dev's guidance on this. Cheers, - Yaniv
On Sun, 16 May 2010 11:55:14 +1000 Yaniv Aknin <yaniv@aknin.name> wrote:
Is the whole notion of a frozendict worthy, given this limitation?
I don't think so. Of course we how have a more general problem: - if we choose to implement only equality testing for partials and leave hashing as is, then hashing isn't consistent with equality anymore -- which is unacceptable - if we choose to implement only equality testing for partials and make them unhashable, we are breaking programs which store partials in a set or a dict So we are left with the following choice: - implement hashing consistently with equality testing, even though the keyword arguments can be changed later. I think this is acceptable from a practicality standpoint - abandon the whole idea of improving equality testing Regards Antoine.
Antoine Pitrou wrote:
On Sun, 16 May 2010 11:55:14 +1000 Yaniv Aknin <yaniv@aknin.name> wrote:
Is the whole notion of a frozendict worthy, given this limitation?
I don't think so. Of course we how have a more general problem: - if we choose to implement only equality testing for partials and leave hashing as is, then hashing isn't consistent with equality anymore -- which is unacceptable - if we choose to implement only equality testing for partials and make them unhashable, we are breaking programs which store partials in a set or a dict
So we are left with the following choice: - implement hashing consistently with equality testing, even though the keyword arguments can be changed later. I think this is acceptable from a practicality standpoint
Another option is to compare the keywords by identity rather than value. This is likely to be more correct anyway, since items may compare equal without giving the same result for all functions:
dict(a=1) == dict(a=1.0) True partial(type, 1)() <type 'int'> partial(type, 1.0)() <type 'float'>
Once you're comparing the supplied arguments by identity rather than value, the question of hashability goes away. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (3)
-
Antoine Pitrou -
Nick Coghlan -
Yaniv Aknin