Raymond Hettinger wrote:
> > On May 3, 2020, at 6:19 PM, Steven D'Aprano st...@pearwood.info wrote:
> > frozenset and set make a counterexample:
> > frozenset({1}) == {1}
> > True
> > Nice catch! That's really interesting. Is there reasoning
> > behind
> > frozenset({1}) == {1} but [1] != (1,), or is it just an accident
> > of
> > history?
> > Conceptually, sets are sets, whether they are mutable or frozen.
> > Right. This isn't an accident. It is by design.
> Also, some numeric types are specifically designed for cross-type comparison:
> >>> int(3) == float(3) == complex(3, 0)
> True
>
> And in Python 2, by design, str and unicode were comparable:
> >>> u'abc' == 'abc'
> True
>
> But the general rule is that objects aren't cross-type comparable by default.
> We have
> to specifically enable that behavior when we think it universally makes
> sense. The modern
> trend is to avoid cross-type comparability, enumerates and data classes for
> example:
> >>> Furniture = Enum('Furniture', ('table', 'chair', 'couch'))
> >>> HTML = Enum('HTML', ('dl', 'ol', 'ul', 'table'))
> >>> Furniture.table == HTML.table
> False
>
> >>> A = make_dataclass('A', 'x')
> >>> B = make_dataclass('B', 'x')
> >>> A(10) == B(10)
> False
>
> Bytes and str are not comparable in Python 3:
> >>> b'abc' == 'abc'
> False
>
> > Isn't a tuple
> > essentially just a frozenlist? I know the intended
> > semantics of tuples and lists tend to be different, but I'm not sure that's
> > relevant.
> > In terms of API, it might look that way. But in terms of use cases, they
> are less alike: lists-are-looping, tuples-are-for-nonhomongenous-fields.
> List are like
> database tables; tuples are like records in the database. Lists are like C
> arrays;
> tuples are like structs.
> On the balance, I think more harm than good would result from making sequence
> equality
> not depend on type. Also when needed, it isn't difficult to be explicit that
> you're
> converting to a common type to focus on contents:
> >>> s = bytes([10, 20, 30])
> >>> t = (10, 20, 30)
> >>> list(s) == list(t)
>
> When you think about it, it makes sense that a user gets to choose whether
> equality is
> determined by contents or by contents and type. For some drinkers, a can of
> beer is equal
> to a bottle of bear; for some drinkers, they aren't equal at all ;-)
> Lastly, when it comes to containers. They each get to make their own rules
> about what
> is equal. Dicts compare on contents regardless of order, but OrderedDict
> requires that
> the order matches.
> Raymond
`(frozenset() == set()) is True` shocked me.
According to wikipedia https://en.wikipedia.org/wiki/Equality_(mathematics):
"equality is a relationship between two quantities or, more generally two
mathematical expressions, asserting that the quantities have the same value, or
that the expressions represent the same mathematical object."
If lists and tuples are considered different "mathematical objects" (different
types), they cannot be considered equal --tough they can be equivalent, for
instance `([1, 2, 3] == list((1, 2, 3)) and tuple([1, 2, 3]) == (1, 2, 3)) is
True`.
I can only explain `(frozenset() == set()) is True` vs `(list() == tuple()) is
False` if:
a) `frozenset`s and `set`s are considered the same "mathematical objects". So
immutability vs mutability is not a relevant feature in Python equality
context. Then, `list() == tuple()` should be `True` if no other feature
distinguishes lists from tuples, I suppose...
b) language designers found `(frozenset() == set()) is True` convenient (why?).
Then, why is not `(list() == tuple()) is True` so convenient?
c) it is a bug and `frozenset() == set()` should be `True`.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KWMD2ILZ4YN3V2A75HCDFX7YIL7S5FWL/
Code of Conduct: http://python.org/psf/codeofconduct/
