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?

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.