Many thanks for reviewing, Stefan, and for the patch.

Here's an updated patch:
 - specify 32-bit/64-bit C long rather than 32-bit/64-bit machine
 - apply hash->hash_ fix to Python hash recipe
 - use _PyHASH_MODULUS instead of _PyHASH_MASK throughout (this
   was bugging me).
 - reorganize the stdtypes doc entry slightly
 - update against current svn, and remove outdated test_float tests
   for the values of float('inf') and float('nan')

One unresolved issue:  it would probably make sense to specify (publicly) a hash algorithm for complex types, too, so that someone implementing e.g. Gaussian integers can make their hash function agree with that for the complex type where appropriate.

That hash algorithm would probably be as simple as:

  hr = hash(x.real)
  hi = hash(x.imag)
  return <some suitably bit-mixing combination of hi and hr>

where the algorithm for the combination needs to be specified explicitly, and any relevant parameters put into sys.hash_info.
(Unfortunately, -1 doesn't have square roots modulo the prime P used, else we could do the cute thing and make use of a square root of -1 modulo P.)

Another tiny detail:  I'm wondering whether hash(m/P) should care about the sign of m:  currently it doesn't, which means that the symmetry hash(-x) = -hash(x) *almost* always holds for a rational x, but not always.  An almost-always-true symmetry seems like a recipe for hard-to-find bugs.