Feature proposal: unittest.mock.NAN

Ideas
21

All that IEEE 754 specifies is the behaviors of value comparisons, not identity comparisons. No one ever uses identity comparison for float objects in Python when they perform numeric operations, so there should be absolutely no negative impact to change the behavior of identity comparison of NaN to an actually useful one by interning it.

Why refactor unit test methods to special-case NaNs to call math.isnan on all tuple items incurring colossal efficiency penalties when a simple interning would efficiently solve the problem?

Please give us a concrete real-world example of what would be negatively impacted with this proposed change.

1 Like
22

Anything that makes use of NaN payloads, which would instantly stop working once there is only one NaN object.

1 Like
23

OK I see your point being that NaNs can be signaling, but it really isn’t a Python issue since there is no support for signaling NaNs in Python:

So perhaps we can just focus on making NaNs in Python the same object and forget about NaN in 3rd-party libraries for now.

1 Like
24

One thing is no support for the signaling behavior, and a different one is removing altogether the payload information. In the latter, it would prevent using Python as an intermediary between software that does use the payload, or at least prevent load the data into float.

One of these would start being False.

from struct import pack, unpack

pack('f', unpack('f', b'\x00\x00\xc0\x7f')[0]) == b'\x00\x00\xc0\x7f'
pack('f', unpack('f', b'\x01\x00\xc0\x7f')[0]) == b'\x01\x00\xc0\x7f'
3 Likes