So here's the plan for trunk.  The big question is:  what should be done for py3k?

For trunk:

 - all comparisons (==, !=, <=, >=, <, >) between floats and Decimals
   return the correct numerical result, as though the float were
   converted to a Decimal with no loss of precision.  Like-signed float
   and Decimal infinities compare equal.  float and Decimal nans compare
   unequal to everything else, as always.

 - check whether anything special needs to be done to make sure that
   cmp also returns sensible results.

 - fix Decimal.__hash__ so that when x == y for a float x and Decimal
   instance y, hash(x) == hash(y)

 - the hash fix above is going to slow down hash computations, so
   consider caching hash values for Decimal instances (as a _hash
   attribute on the Decimal object itself).  My gut feeling is that
   this probably isn't worth it, given that Decimal objects probably
   don't get hashed very often in normal use, but I'll do some timings
   to find out what the performance impact of the new hash is.

For py3k, the obvious options are:

(A) adopt the above changes, or

(B) keep Decimal and float non-comparable (as currently).  In this case, a Decimal-to-float comparison in trunk should probably raise a DeprecationWarning.  (Note that DeprecationWarnings are now silent by default, so such a warning wouldn't impact end-users much.)