Here is a patch to make PyFloat_FromDouble(0.0) always return the same 
float instance.  This is similar to the existing optimization in 
PyInt_FromLong(x) for small x.

My own motivation is that the patch reduces memory by several megabytes 
for a particular in-house data processing script, but I think that it 
should be generally useful assuming that zero is a very common float 
value, and at worst almost neutral when this assumption is wrong.  The 
minimal performance impact of the test for zero should be easily 
recovered by reduced memory allocation calls.  I am happy to look into 
benchmarking if you require empirical performance data.

Will it correctly distinguish between +0.0 and -0.0?

No it won't distinguish between +0.0 and -0.0 in its present form,
because these two have the same value according to the C equality
operator.  This should be easy to adjust, eg we could exclude -0.0 by
changing the comparison
    if (fval == 0.0)
into 
    static double positive_zero = 0.0;
    ...
    if (!memcmp(&fval, &positive_zero, sizeof(double)))

We need maybe more hardcoded floats. I mean a "cache" of current 
float. Example of pseudocode:

def cache_float(value):
   return abs(value) in (0.0, 1.0, 2.0)

def create_float(value):
   try:
      return cache[value]
   except KeyError:
      obj = float(value)
      if cache_value(value):
         cache[value] = obj
      return obj

Since some (most?) programs don't use float, the cache is created on 
demand and not at startup.

Since the goal is speed, only a benchmark can answer to my question 
(is Python faster using such cache) ;-) Instead of cache_float(), an 
RCU cache might me used.

Please use copysign(1.0, fval) == 1.0 instead of your memcpy trick. It's
the cannonical way to check for negative zero. copysign() is always
available because we have our own implementation if the platform doesn't
provide one. We might also want to special case 1.0 and -1.0.

I've to check with Guido and Barry if we can get the optimization into
2.6.1 and 3.0.1. It may have to wait until 2.7 and 3.0.

I question whether this should be done at all.  Making the creation of a
float even slightly slower is bad.  This is on the critical path for all
floating point intensive computations.  If someone really cares about
the memory savings, it is not hard take a single in instance of float
and use it everywhere:  ZERO=0.0; arr=[ZERO if x == 0.0 else x for x in
arr].  That technique also works for 1.0 and -1.0 and pi and other
values that may commonly occur in a particular app.  Also, the technique
is portable to implementations other than CPython.  I don't mind this
sort of optimization for immutable containers but feel that floats are
too granular.  Special cases aren't special enough to break the rules. 
If the OP is insistent, then at least this should be discussed with the
numeric community who will have a better insight into whether the
speed/space trade-off makes sense in other applications beyond the OP's
original case.

Tim, any insights?

I have 3 comments for future readers who might want to reopen.

1) This would have little effect on calculation with numpy.

2) According to sys.getrefcount, when '>>>' appears, 3.0.1 has 1200
duplicate references to 0 and 1 alone, and about 2000 to all of them. 
So so small int caching really needs to be done by the interpreter.  Are
there *any* duplicate internal references to 0.0 that would help justify
this proposal?

3) It is? (certainly was) standard in certain Fortran circles to NAME
constants as Raymond suggested.  One reason given was to ease conversion
between single and double precision.  In Python, named constants in
functions would ease conversion between, for instance, float and decimal.