Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!news2.arglkargh.de!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!shaftesbury.zen.co.uk.POSTED!not-for-mail
From: Nobody <nobody@nowhere.com>
Subject: Re: float("nan") in set or as key
Date: Sun, 05 Jun 2011 19:15:02 +0100
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
Message-Id: <pan.2011.06.05.18.14.58.407000@nowhere.com>
Newsgroups: comp.lang.python
References: <mailman.2206.1306626083.9059.python-list@python.org> <94dkd3F7k4U1@mid.individual.net> <4de1e3e7$0$2195$742ec2ed@news.sonic.net> <4de22007$0$29996$c3e8da3$5496439d@news.astraweb.com> <pan.2011.05.29.21.19.12.375000@nowhere.com> <4de2d746$0$29996$c3e8da3$5496439d@news.astraweb.com> <pan.2011.06.01.20.40.18.453000@nowhere.com> <4de75dd5$0$29983$c3e8da3$5496439d@news.astraweb.com> <pan.2011.06.02.20.47.01.344000@nowhere.com> <isasfm$inl$1@reader1.panix.com> <pan.2011.06.03.23.29.04.984000@nowhere.com> <4deb2e65$0$29996$c3e8da3$5496439d@news.astraweb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Lines: 25
Organization: Zen Internet
NNTP-Posting-Host: 57074da8.news.zen.co.uk
X-Trace: DXC=fZZbAOUYa\]G`MCLM<O\ZTnok4Z\<mH4YhDU:2=XKPkXIkoQHn2kY<YQOMCU8L]ShWONX2\Y<EfGR
X-Complaints-To: abuse@zen.co.uk
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:7053

On Sun, 05 Jun 2011 07:21:10 +0000, Steven D'Aprano wrote:

> Returning a sentinel meaning "an exceptional event occurred" is hardly 
> unusual, even in Python. str.find() does is, as does re.search() and 
> re.match().

These are not "exceptional" conditions; if they were, an exception would
be used.

E.g. dict supports both d.get(key) and d[key] for lookups. The former
returns a sentinel, the latter raises an exception. The latter makes sense
if you "expect" the key to be present, the former if you don't.

>> As for IEEE-754 saying that it's [NAN == NAN] True: they only really
>> had two choices: either it's True or it's False.
> 
> Incorrect. They could have specified that it was an error, like dividing 
> by zero, but they didn't.

Specifying an error doesn't remove the requirement to also specify a
result. E.g. dividing a finite value by zero produces a result of
infinity. In languages which lack exceptions, errors only matter if the
code bothers to check for them (if such checks are even possible; C89
lacks <fenv.h>).