On 4/28/2011 12:32 AM, Nick Coghlan wrote: 
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman <v+python@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@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.