Showing content from http://mail.python.org/pipermail/python-dev/attachments/20110428/92a01b0b/attachment.html below:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#330033" bgcolor="#ffffff">
On 4/27/2011 11:54 PM, Nick Coghlan wrote:
<blockquote
cite="mid:BANLkTi=eAug-2n+MsQvSpaet5PM4NQDHSg@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Apr 28, 2011 at 4:20 PM, Glenn Linderman <a class="moz-txt-link-rfc2396E" href="mailto:v+python@g.nevcal.com"><v+python@g.nevcal.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In that bug, Nick, you mention that reflexive equality is something that
container classes rely on in their implementation. Such reliance seems to
me to be a bug, or an inappropriate optimization, rather than a necessity.
I realize that classes that do not define equality use identity as their
default equality operator, and that is acceptable for items that do not or
cannot have any better equality operator. It does lead to the situation
where two objects that are bit-for-bit clones get separate entries in a
set... exactly the same as how NaNs of different identity work... the
situation with a NaN of the same identity not being added to the set
multiple times seems to simply be a bug because of conflating identity and
equality, and should not be relied on in container implementations.
</pre>
</blockquote>
<pre wrap="">
No, as Raymond has articulated a number of times over the years, it's
a property of the equivalence relation that is needed in order to
present sane invariants to users of the container. </pre>
</blockquote>
<br>
I probably wasn't around when Raymond did his articulation :) Sorry
for whatever amount of rehashing I'm doing here -- pointers to some
of the articulation would be welcome, but perhaps the summary below
is intended to recap the results of such discussions. If my
comments below seem to be grasping the essence of those discussions,
then no need for the pointers... if I'm way off, I'd like to read a
thread or two.<br>
<br>
<blockquote
cite="mid:BANLkTi=eAug-2n+MsQvSpaet5PM4NQDHSg@mail.gmail.com"
type="cite">
<pre wrap="">I included in the
bug report the critical invariants I am currently aware of that should
hold, even when the container may hold types with a non-reflexive
definition of equality:
assert [x] == [x] # Generalised to all container types
assert not [x] != [x] # Generalised to all container types
for x in c:
assert x in c
assert c.count(x) > 0 # If applicable
assert 0 <= c.index(x) < len(c) # If applicable
The builtin types all already work this way, and that's a deliberate
choice - my proposal is simply to document the behaviour as
intentional, and fix the one case I know of in the standard library
where we don't implement these semantics correctly (i.e.
collections.Sequence).
The question of whether or not float and decimal.Decimal should be
modified to have reflexive definitions of equality (even for NaN
values) is actually orthogonal to the question of clarifying and
documenting the expected semantics of containers in the face of
non-reflexive definitions of equality.
</pre>
</blockquote>
<br>
Yes, I agree they are orthogonal questions... separate answers and
choices can be made for specific classes, just like some classes
implement equality using identity, it would also be possible to
implement identity using equality, and it is possible to conflate
the two as has apparently been deliberately done for Python
containers, without reflecting that in the documentation.<br>
<br>
If the containers have been deliberately implemented in that way,
and it is not appropriate to change them, then more work is needed
in the documentation than just your proposed Glossary definition, as
the very intuitive descriptions in the Comparisons section are quite
at odds with the current implementation.<br>
<br>
Without having read the original articulations by Raymond or any
discussions of the pros and cons, it would appear that the above
list of invariants, which you refer to as "sane", are derived from a
"pre-NaN" or "reflexive equality" perspective; while some folk
perhaps think the concept of NaN is a particular brand of insanity,
it is a standard brand, and therefore worthy of understanding and
discussion. And clearly, if the NaN perspective is intentionally
corralled in Python, then the documentation needs to be clarified.
On the other hand, the SQL language has embraced the same concept as
NaN in its concept of NULL, and has pushed that concept (they call
it three-valued logic, I think) clear through the language. NULL ==
NULL is not True, and it is not False, but it is NULL. Of course,
the language is different in other ways that Python; values are not
objects and have no identity, but they do have collections of values
called tuples, columns, and tables, which are similar to lists and
lists of lists. And they have mappings called indexes. And they've
made it all work with the concept of NULL and three-valued logic.
And sane people work with database systems built around such
concepts. So I guess I reject the argument that the above
invariants are required for sanity.<br>
<br>
On the other hand, having not much Python internals knowledge as
yet, I'm in no position to know how seriously things would break
internally should a different set of invariants that embrace and
extend the concept of non-reflexive equality were to be invented to
replace the above, nor whether there is a compatible migration path
to achieve it in a reasonable manner... from future import NaNsanity
... :)<br>
</body>
</html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4