The problem doesn't seem to be with passing the string representation. It looks to be a problem with the function's logic itself.

|5> np.issubdtype(np.dtype('float64'), np.dtype('float32'))
True

|8> np.issubdtype(np.dtype(np.float64), np.dtype(np.float32))
True

https://github.com/numpy/numpy/blob/master/numpy/core/numerictypes.py#L767

I don't understand the point of this if suite. Why would we go up one level in the MRO (in this case, from np.float32 to np.floating)? Why wouldn't we just use np.issubclass_(np.dtype(arg1).type, np.dtype(arg2).type)?

If anyone wants to address it, gh-2334 is probably related.

Still in 1.9-devel. Robert's suggestion looks good, so marking this easy fix.

Although it probably gets complicated ;)

I was trying to understand the dtype hierarchy and was confused when the same bug reported here was occurring. It looks like it can be easily fixed, according to the solution suggested above. It would be great if anyone could tell if this issue has been left for a reason, since it looks like a confusing behavior.

And any suggestions regarding the safety of np.issubclass_, which is basically the issubclass function, with False being returned instead of raising a TypeError.

In the current implementation, as pointed out in the documentation, even a call of

>>>issubclass(np.dtype('float64'),np.generic)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: issubclass() arg 1 must be a class
>>> np.issubclass_(np.dtype('float64'),np.generic)
False

just returns False, which was one of the reasons for the cause of the present confusion. It would be better if the exception can be caught and a proper error message printed out that the argument was a dtype object, rather than a type class

>>> type(np.dtype('float'))
<type 'numpy.dtype'>
>>> type(np.dtype('float').type)
<type 'type'>

>>> inspect.isclass(np.dtype('float'))
False
>>> inspect.isclass(np.dtype('float').type)
True

This function is (sans doc-string):

def issubdtype(arg1, arg2):
    if issubclass_(arg2, generic):
        return issubclass(dtype(arg1).type, arg2)
    mro = dtype(arg2).type.mro()
    if len(mro) > 1:
        val = mro[1]
    else:
        val = mro[0]
    return issubclass(dtype(arg1).type, val)

This just seems strange, Why isn't it:

def issubdtype(arg1, arg2):
    if issubclass_(arg2, generic):
        return issubclass(dtype(arg1).type, arg2)
    return issubclass(dtype(arg1).type, dtype(arg2).type)

Instead? This avoids the issue that @cpascual describes.

What is the point of the conditional mro-traversing?

Deprecated in #9505:

>>> np.issubdtype(np.float64,np.float32)
False
>>> np.issubdtype('float64','float32')
FutureWarning: Conversion of the second argument of issubdtype from `'float32'` to `np.floating` is deprecated.
In future, it will be treated as `np.float32 == np.dtype('float32').type`.
True