[Python-Dev] PyObject_RichCompareBool identity shortcut

[Glenn Linderman]

On 4/28/2011 12:32 AM, Nick Coghlan wrote:
> On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman<v+python at g.nevcal.com>  wrote:
>> Without having read the original articulations by Raymond or any discussions
>> of the pros and cons,
> In my first post to this thread,  I pointed out the bug tracker item
> (http://bugs.python.org/issue4296) that included the discussion of
> restoring this behaviour to the 3.x branch, after it was inadvertently
> removed.

Sure.  I had read that.  It was mostly discussing it from a backward 
compatibility perspective, although it mentioned some invariants as 
well, etc.

But mentioning the invariants is different than reading discussion about 
the pros and cons of such, or what reasoning lead to wanting them to be 
invariants.  Raymond does make a comment about necessary for correctly 
reasoning about programs, but that is just a tautological statement 
based on previous agreement, rather than being the discussion itself, 
which must have happened significantly earlier.

One of your replies to Alexander seems to say the same thing I was 
saying, though....

On 4/28/2011 12:57 AM, Nick Coghlan wrote:
>> On Thu, Apr 28, 2011 at 5:30 PM, Alexander Belopolsky
>> <alexander.belopolsky at gmail.com>  wrote:
>> Can you give examples of algorithms that would break if one of your
>> >  invariants is violated, but would still work if the data contains
>> >  NaNs?
> Sure, anything that cares more about objects than it does about
> values. The invariants are about making containers behave like
> containers as far as possible, even in the face of recalcitrant types
> like IEEE754 floating point.

That reinforces the idea that the discussion about containers was to try 
to make them like containers in pre-NaN languages such as Eiffel, rather 
than in post-NaN languages such as SQL.  It is not that one cannot 
reason about containers in either case, but rather that one cannot 
borrow all the reasoning from pre-NaN concepts and apply it to post-NaN 
concepts.  So if one's experience is with pre-NaN container concepts, 
one pushes that philosophy and reasoning instead of embracing and 
extending post-NaN concepts.  That's not all bad, except when the 
documentation says one thing and the implementation does something 
else.  Your comment in that same message "we can contain the damage to 
some degree" speaks to that philosophy.  Based on my current limited 
knowledge of Python internals, and available time to pursue figuring out 
whether the compatibility issues would preclude extending Python 
containers to embrace post-NaN concepts, I'll probably just learn your 
list of invariants, and just be aware that if I need a post-NaN 
container, I'll have to implement it myself.  I suspect doing sequences 
would be quite straightforward, other containers less so, unless the 
application of concern is sufficiently value-based to permit the trick 
of creating a new NaN each time it is inserted into a different container.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110428/cfd5bfeb/attachment.html>