# [Python-Dev] Got None. Maybe Some?

Josiah Carlson jcarlson at uci.edu
Mon Dec 22 03:13:14 EST 2003

```I just realized I've been forgetting to CC the list.

It is a bit long, but I'll cut out the non-relevant portions that
everyone has seen before.  In chronological order below.

I ask the rest of you, does Some sound so crazy?
- Josiah

*** message from Josiah Carlson on Sun, 21 Dec 2003 19:05:45 -0800 ***

> -1.  Depending on your algorithm you can already use sys.maxint, or a
> large float (e.g. 1e300), or you can write 1e1000 (or 1e300**2) which
> on most systems evaluates to a floating point Infinity.  And "Some"
> sounds like a really strange spelling of "Infinity".  There's also a
> PEP (PEP 754) to add a proper way to spell floating point Infinity.
> Or you could reverse signs and use min(None, -a).
>

I've read PEP 754, and yes, the author talks about having a proper
Infinity, -Infinity and Not a Number (PosInf, NegInf and NaN
respectively), but considering that it has been in the 'draft' state
since March 28, has not been updated, and it doesn't seem like Python is
any closer to having proper definitions now than it was ~9 months ago,
I'm not going to put my eggs in the IEEE 754 Infinity basket.

In terms of having something useful on a platform, there is only so
useful that infinity can be.  The below is from the windows verstion of
Python 2.3.2
>>> 1e309
1.#INF
>>> -1e309
-1.#INF
>>> 1.#INF
1.0
>>> max(1e309, 0)
1.#INF
>>> min(1e309, 10**309)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to float

The real trick is that it is not so much about being able to have
max(Some, a) -> Some, it is about being able to have min(Some, a) -> a.
Then you don't need to worry about sys.maxint not being big enough
(because there are larger numbers), nor do you need to worry about
float casts of large integers producing OverflowErrors.

As for an application, many path searches in graphs start out with
initializing distances to infinity, Some would be suitable for this.
Other algorithms require a negative infinity for this, None has been
working fine.  As an initialization value, I believe that Some would be
quite a useful object.

Certainly Some seems like a strange way to spell infinity, but it is a
logical infinity, one that you can compare things against, anything, not
just Python floats or things that can be cast into Python floats.

In terms if PEP 754, if it were actually implemented, certainly there
would be some question as to whether Some would be equal to PosInf.  If
so, then would -Some be equal to NegInf?  And if so, would None be equal
to NegInf?  Maybe such things would require a float cast.

I talk about all this in my PEP submission, which isn't up yet.  I
suppose I probably should have given it a few days before discussing it,
but yeah.

- Josiah
*** end message from Josiah ***

*** message from Guido van Rossum on Sun, 21 Dec 2003 20:45:34 -0800 ***

> I've read PEP 754, and yes, the author talks about having a proper
> Infinity, -Infinity and Not a Number (PosInf, NegInf and NaN
> respectively), but considering that it has been in the 'draft' state
> since March 28, has not been updated, and it doesn't seem like Python is
> any closer to having proper definitions now than it was ~9 months ago,
> I'm not going to put my eggs in the IEEE 754 Infinity basket.

I expect your PEP will fare no better, and given its weirdness,
probably much worse.  Do you know of any language that has a similar
concept?

*** end message from Guido ***

*** message from Josiah Carlson on Sun, 21 Dec 2003 21:47:34 -0800 ***

> I expect your PEP will fare no better, and given its weirdness,
> probably much worse.  Do you know of any language that has a similar
> concept?

Is None so weird?  All I am proposing is a symmetric value to None.
Just like there is a -1 and 1, -Infinity and Infinity, None logically
should have Some.  Maybe not so much -Some == None, but as I propose in
the PEP, possibly Some == not None.

- Josiah
*** end message from Josiah ***

```