Showing content from http://mail.python.org/pipermail/python-dev/attachments/20110428/cfd5bfeb/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/28/2011 12:32 AM, Nick Coghlan wrote:
<blockquote
cite="mid:BANLkTikGVfox3dXkO7B5f5iQbX5L8ypNgw@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Apr 28, 2011 at 5:27 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="">Without having read the original articulations by Raymond or any discussions
of the pros and cons,
</pre>
</blockquote>
<pre wrap="">
In my first post to this thread, I pointed out the bug tracker item
(<a class="moz-txt-link-freetext" href="http://bugs.python.org/issue4296">http://bugs.python.org/issue4296</a>) that included the discussion of
restoring this behaviour to the 3.x branch, after it was inadvertently
removed.
</pre>
</blockquote>
<br>
Sure. I had read that. It was mostly discussing it from a backward
compatibility perspective, although it mentioned some invariants as
well, etc.<br>
<br>
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.<br>
<br>
One of your replies to Alexander seems to say the same thing I was
saying, though....<br>
<br>
On 4/28/2011 12:57 AM, Nick Coghlan wrote:
<blockquote
cite="mid:BANLkTik8gRUPt2jxSkbEy9GVo1nzdFT0dg@mail.gmail.com"
type="cite">
<blockquote type="cite" style="color: rgb(0, 0, 0);">
<pre wrap="">On Thu, Apr 28, 2011 at 5:30 PM, Alexander Belopolsky
<a class="moz-txt-link-rfc2396E" href="mailto:alexander.belopolsky@gmail.com"><alexander.belopolsky@gmail.com></a> wrote:
Can you give examples of algorithms that would break if one of your
<span class="moz-txt-citetags">> </span>invariants is violated, but would still work if the data contains
<span class="moz-txt-citetags">> </span>NaNs?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<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