<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 21, 2014 at 1:11 PM, David Mertz <span dir="ltr"><<a href="mailto:mertz@gnosis.cx" target="_blank">mertz@gnosis.cx</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Slightly related, here's an invariant that I've wished would hold for a decade, but isn't likely to, even in Python 4:<div><br></div><div> assert all(not x<y for x,y in zip(a,b)) if a==b else False<br>
</div></div></blockquote><div><br></div><div>Ooops, I meant:</div><div><br></div><div> assert all(not x<y for x,y in zip(a,b)) if a==b else True</div><div><br></div><div>But the point is that it fails where a==b because equal elements may not be "not unequal."</div>
<div><br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>But this is just a question of inequality versus identity and that sets and dictionaries are, IMO, too sloppy about that. That is, they behave exactly as documented and as the BDFL has decreed, but I still feel uneasy about:<br>
</div></blockquote></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div><div> >>> a = {1, 1+0j, 2}</div><div> >>> b = {1+0j, 1, 2}</div><div> >>> a<br></div><div> {(1+0j), 2}</div><div> >>> b</div><div> {1, 2}</div><div> >>> a == b</div>
<div> True</div></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 1:02 PM, David Mertz <span dir="ltr"><<a href="mailto:mertz@gnosis.cx" target="_blank">mertz@gnosis.cx</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
Imagine implementing min and max this way (ignoring key= and the<br>
possibility of a single iterable arg):<br>
<br></div><div>lst = sorted((x,y))<br>
assert lst == [min(lst), max(lst)]<br>
<br>
will pass for any x and y.<br></div></blockquote><div><br></div><div>Well, that's not possible, of course, if one is willing to be slightly perverse:</div><div><br></div><div><div>>>> @total_ordering</div><div>
... class SomewhatOrdered(object):</div>
<div>... def __init__(self, val):</div><div>... self.val = val</div><div>... def __eq__(self, other):</div><div>... return self.val == other.val</div><div>... def __lt__(self, other):</div><div>
... return (self.val, random()) < (other.val, random())</div><div>... def __repr__(self):</div><div>... return repr(self.val)</div><div>...</div><div>>>> x, y, z = map(SomewhatOrdered, (1, 1.0, 2))</div>
</div><div><br></div><div>But even if you were slightly less perverse than this, *sets* (and set-like collections) return elements in indeterminate order which the language does not guarantee. In particular, I do not think we are promised this holds:</div>
<div><br></div><div> assert tuple(a)==tuple(b) if a==b else False</div><div><br></div></div>I can certainly construct a class where that won't hold (i.e. a set-like class that iterates in a non-deterministic order; this need not even be perverse, e.g. if it is 'AsyncResultsSet' that gets its data from I/O source or parallel computations).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I have a feeling I could find plain old Python sets that would fail that, but I'm not sure about it.<span><font color="#888888"><br clear="all">
<div><br></div>-- <br>Keeping medicines from the bloodstreams of the sick; food <br>
from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons. Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>
advocates of freedom in prisons. Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>
advocates of freedom in prisons. Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br>
</div></div>