COMPAT: ndt / numpy dtype hierarchy

[jreback]

xref #149

The dtype hierarchy appears not to be consistent.

E.g. what corresponds to np.floating? (ndt.float64 exists though) and np.integer (e.g. the super-set of the 'basic' dtypes)

I need to do type checking like this:

if isinstance(dtype, np.integer):
 ....

so ideally I could simply do this:

if _DYND_INSTALLED:
   np.integer = ndt.integer

....

if isinstance(dtype, np.integer):
   ....

or if needbe

if isintance(dtype, np.integer) or (_DYND_INSTALLED and isinstance(dtype, ndt.integer)):
   ...

[mwiebe]

Something based on https://docs.python.org/3.4/library/numbers.html would be nice to do.

[jreback]

@mwiebe

should this work?

ndt.type('?int32') == '?int32'? (e.g. the str repr of the lhs is the same, but to you coerce the rhs?)

[cpcloud]

hm that reminds of javascript. how about a compromise: ndt.type('?int32') == dshape('?int32')?

[mrocklin]

Hrm, maybe we should do dshape('?int32') == '?int32' in datashape?

Of course, once you overload __eq__ a number of other subtle problems pop up. It's an expensive convenience.

[mwiebe]

@jreback Ideally I'd like the ndt.type object to follow Python standards for hashability, just like I wrote for NumPy dtypes a long time ago here:

https://github.com/numpy/numpy/issues/1725

==hashable== An object is hashable if it has a hash value which never changes during its lifetime (it needs a hash() method), and can be compared to other objects (it needs an eq() or cmp() method). Hashable objects which compare equal must have the same hash value.

Hashability makes an object usable as a dictionary key and a set member, because these data structures use the hash value internally.

All of Python’s immutable built-in objects are hashable, while no mutable containers (such as lists or dictionaries) are. Objects which are instances of user-defined classes are hashable by default; they all compare unequal, and their hash value is their id().

Is it too much of a stretch to hope for this, or do you think there might be a way this could be workable?

[cpcloud]

Of course, once you overload __eq__ a number of other subtle problems pop up. It's an expensive convenience.

Strongly agree with that. I'm kind of -1 on making strings mean something else for programmer convenience.

[cpcloud]

Just to expand on the javascript similarity here: JavaScript does this for its == operator. Coerces everything to common type and then does ===. It was one of the worst language design choices in history.

[cpcloud]

I'm definitely +1 on an expanded type hierarchy and -1 on allowing string comparison