# [Python-ideas] Add dict.getkey() and set.get()

David Mertz mertz at gnosis.cx
Sat Sep 14 20:20:53 CEST 2013

```On Sat, Sep 14, 2013 at 10:56 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> Sets presume that == is an equivalence relation. When that is not true, as
> for such FuzzyNumbers (which break transitivity), they should not be used
> with sets at all, as many operations will be somewhat broken. For one
> thing, the composition of such 'sets' will depend on the order of addition.
>

I'm not putting any huge weight in my toy class.  But notice that it
deliberately is NOT hashable, hence cannot make it into a set (or dict key):

>>> fn = FuzzyNumber(7.5)
>>> d = {fn: "fuzzy"}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'FuzzyNumber'

What the hypothetical class might be useful for, in my passing thought, is
for e.g. an imprecise measurement of something.  Any value that is "close"
is equal within the error of measurement. Hence perhaps we want to be able
to say:

>>> [x for x in (1,2, 7.2, 7.3, 7.9, 8.0, 9) if x==fn]
[7.2, 7.3, 7.9]

I do know one *could* spell that like:

>>> [x for x in (1,2, 7.2, 7.3, 7.9, 8.0, 9) if ref_val.close_to(x)]

But anyway, whether or not my FuzzyNumber class is a *good* idea, it is
something that end users *could* do as long as we give them an .__eq__()
magic method to play with.  Hence a 'getexact()' function or a
dict.getkey() method would have to do SOMETHING when presented with such a
transitivity-of-equality-breaking object.

>
>
>
>   >>> d = {2: 'a', 5.0: 'b', 7.2: 'low', 7.6: 'high'}
>>  >>> class FuzzyNumber(float):
>> ...     def __eq__(self, other):
>> ...         return abs(self-other) < 0.5
>>
>
> Better to call this method 'similar' or 'is_similar', since similarity is
> not expected to be transitive.
>
>
>   >>> fn = FuzzyNumber(7.5)
>>  >>> getexact(d, fn) # What gets returned here?!
>> 7.6
>>
>> ANY implementation of this idea would either have to pick the arbitrary
>> first match, or ... well, something else.  Equality isn't actually
>> transitive across all Python objects...
>>
>
> Except for NaNs, the non-floats called floats for the benefit of languages
> with typed operations, I believe equality is (at least as far as possible)
> transitive for the built-in classes as delivered. We fixed
>   0.0 == 0 == Decimal(0) != 0.0
> because of the problems caused by the non-transitivity. Avoiding breaking
> transitivity was one of the design constraints of the Enums.
>
>
> > and even my quick example isn't
>
>> a completely absurd data type (it would need to be fleshed out better,
>> but a FuzzyNumber could well have sensible purposes).
>>
>
> The only absurd thing is calling similarity 'equality' ;=).
>
> --
> Terry Jan Reedy
>
>
> ______________________________**_________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/**mailman/listinfo/python-ideas<https://mail.python.org/mailman/listinfo/python-ideas>
>

--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...