[Python-Dev] PyObject_RichCompareBool identity shortcut

Glenn Linderman v+python at g.nevcal.com
Thu Apr 28 08:20:56 CEST 2011


On 4/27/2011 8:43 PM, Nick Coghlan wrote:
> On Thu, Apr 28, 2011 at 12:42 PM, Stephen J. Turnbull
> <stephen at xemacs.org>  wrote:
>> Mark Dickinson writes:
>>
>>   >  Declaring that 'nan == nan' should be True seems attractive in
>>   >  theory,
>>
>> No, it's intuitively attractive, but that's because humans like nice
>> continuous behavior.  In *theory*, it's true that some singularities
>> are removable, and the NaN that occurs when evaluating at that point
>> is actually definable in a broader context, but the point of NaN is
>> that some singularities are *not* removable.  This is somewhat
>> Pythonic: "In the presence of ambiguity, refuse to guess."
> Refusing to guess in this case would be to treat all NaNs as
> signalling NaNs, and that wouldn't be good, either :)
>
> I like Terry's suggestion for a glossary entry, and have created an
> updated proposal at http://bugs.python.org/issue11945
>
> (I also noted that array.array is like collections.Sequence in failing
> to enforce the container invariants in the presence of NaN values)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110427/2618275e/attachment.html>


More information about the Python-Dev mailing list