nan type drift for np.nan about dill HOT 3 OPEN

Python 3.8.18 (default, Aug 25 2023, 04:23:37) 
[Clang 13.1.6 (clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> d = {np.nan: 1234, float('nan'): 4321}
>>> d
{nan: 1234, nan: 4321}
>>> d[np.nan]
1234
>>> d[float('nan')]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: nan
>>> 

...and you are saying that pickling a np.nan can get converted to float('nan') after a dump then load? in some cases, or always?

from dill.

Yeah to my experience this is pretty universal for dill / pickle, even in different import scenarios. I did a little digging and appears that the Numpy version of np.nan refers to some global representation such that the root of matter is that np.nan is np.nan == True while in more generic floats float("nan") is float("nan") == False, where I believe this disparity is source of several other python edge cases like using nan as a key in a dictionary (which is supported for np.nan but not for float("nan").

After thinking about it, for my specific use case in the Automunge library decided to remove exposure to nan dictionary key scenario and use None in place of nan, so if you want to close this issue I think my concern is resolved by that update.

Thanks

from dill.

Python 3.8.18 (default, Aug 25 2023, 04:23:37) 
[Clang 13.1.6 (clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dill
>>> import numpy as np
>>> n = dill.copy(np.nan)
>>> m = dill.copy(float('nan'))
>>> n is np.nan
False
>>> m is np.nan
False
>>> import copy
>>> o = copy.deepcopy(np.nan)
>>> o is np.nan
True

I'm going to reopen this issue, as I think the dill.copy should produce a np.nan and not a nan, and this is something that can be corrected for within dill.

from dill.