Etydhv

The hash of infinity in Python has digits matching pi:

>>> inf = float('inf')
>>> hash(inf)
314159
>>> int(math.pi*1e5)
314159

Is that just a coincidence or is that intentional?

It's not a coincidence; it's explicitly defined that way in the default CPython implementation of Python, and in fact you can even examine this from a Python 3 shell:

>>> import sys
>>> sys.hash_info
sys.hash_info(width=64, modulus=2305843009213693951, inf=314159, nan=0, imag=1000003, algorithm='siphash24', hash_bits=64, seed_bits=128, cutoff=0)
>>> sys.hash_info.inf
314159

Above, the fact that sys.hash_info.inf is 314159 means that 314159 is the hash value returned for positive infinity. (Same results with PyPy too.)

In terms of code, hash is a built-in function. Calling it on a Python float object invokes the function whose pointer is given by the tp_hash attribute of the built-in float type (PyTypeObject PyFloat_Type), which is the float_hash function, defined as return _Py_HashDouble(v->ob_fval), which in turn has

 if (Py_IS_INFINITY(v))
 return v > 0 ? _PyHASH_INF : -_PyHASH_INF;

where _PyHASH_INF is defined as 314159:

#define _PyHASH_INF 314159

In terms of history, the first mention of 314159 in this context in the Python code (you can find this with git bisect or git log -S 314159 -p) was added by Tim Peters in August 2000, in what is now commit 39dce293 in the cpython git repository.

The commit message says:

Fix for http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470.
This was a misleading bug -- the true "bug" was that hash(x) gave an error
return when x is an infinity. Fixed that. Added new Py_IS_INFINITY macro to
pyport.h. Rearranged code to reduce growing duplication in hashing of float and
complex numbers, pushing Trent's earlier stab at that to a logical conclusion.
Fixed exceedingly rare bug where hashing of floats could return -1 even if there
wasn't an error (didn't waste time trying to construct a test case, it was simply
obvious from the code that it *could* happen). Improved complex hash so that
hash(complex(x, y)) doesn't systematically equal hash(complex(y, x)) anymore.

In particular, in this commit he ripped out the code of static long float_hash(PyFloatObject *v) in Objects/floatobject.c and made it just return _Py_HashDouble(v->ob_fval);, and in the definition of long _Py_HashDouble(double v) in Objects/object.c he added the lines:

 if (Py_IS_INFINITY(intpart))
 /* can't convert to long int -- arbitrary */
 v = v < 0 ? -271828.0 : 314159.0;

So as mentioned, it was an arbitrary choice. Note that 271828 is formed from the first few decimal digits of e.

Related later commits:

• By Mark Dickinson in Apr 2010 (also), making the Decimal type behave similarly




• Same, moving the code to the top and adding test cases (also)




• By Mark Dickinson in May 2010, giving the constant a name _PyHASH_INF (also removed the 271828 which is why in Python 3 hash(float('-inf')) returns -314159 rather than -271828 as it does in Python 2)




• By Raymond Hettinger in Jan 2011, adding an explicit example in the "What's new" for Python 3.2 of sys.hash_info showing the above value. (See here.)




• By Stefan Krah in Mar 2012 modifying the Decimal module but keeping this hash.




• By Christian Heimes in Nov 2013, moved the definition of _PyHASH_INF from Include/pyport.h to Include/pyhash.h where it now lives.

_PyHASH_INF is defined as a constant equal to 314159.

I can't find any discussion about this, or comments giving a reason. I think it was chosen more or less arbitrarily. I imagine that as long as they don't use the same meaningful value for other hashes, it shouldn't matter.