[docs] [issue26020] set_display evaluation order doesn't match documented behaviour

[Emanuel Barry]

Emanuel Barry added the comment:

Set displays appear to be the culprit here:

>>> class A:
...   count = 0
...   def __init__(self):
...     self.cnt = self.count
...     type(self).count += 1
...   def __eq__(self, other):
...     return type(self) is type(other)
...   def __hash__(self):
...     return id(type(self))
...
>>> e={A(), A(), A(), A(), A()}
>>> e
{<__main__.A object at 0x002BB2B0>}
>>> list(e)[0].cnt
4
>>> list(e)[0].count
5
>>> A.count = 0
>>> q=set([A(), A(), A(), A(), A()])
>>> q
{<__main__.A object at 0x002BB310>}
>>> list(q)[0].cnt
0
>>> list(q)[0].count
5

I'm guessing this is an optimization and/or set displays just don't keep ordering at definition time.

Do you have a use case where `x == y`/`hash(x) == hash(y)` does not mean that `x` and `y` should be interchangeable? True and 1 are 100% interchangeable, minus their str() output, and my example is very unlikely to ever appear in actual code.

Probably just better to fix the docs to specify that sets literals don't check ordering.

----------
nosy: +ebarry
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26020>
_______________________________________