BUG: np.can_cast fails with string input

[LukasNickel]

Describe the issue:

The can_cast function fails with a rather non-descriptive error if from_ is a string (Or 'None'-descriptive? SCNR).

Since strings are scalars in numpy, I would expect this to return False if comparing to a non-string dtype.
Although on the other hand:

x = np.float32("42.0")
type(x)
>> numpy.float32

works just fine, so maybe one would expect it to return True in some cases as well.

Reproduce the code example:

import numpy as np
np.can_cast("42", np.float32)

Error message:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[112], line 1
----> 1 np.can_cast("42", np.float32)

File <__array_function__ internals>:180, in can_cast(*args, **kwargs)

TypeError: did not understand one of the types; 'None' not accepted

Runtime information:

sys.version:
'3.9.15 | packaged by conda-forge | (main, Nov 22 2022, 15:55:03) \n[GCC 10.4.0]'

np.version:
'1.23.5'

Context for the issue:

I want to convert inputs to the expected dtypes.
My plan was to use np.can_cast(input_value, expected_dtype, casting="safe") to test if the values are valid and can be casted without loss of precision.

I could of course compare the dtypes directly as well and only cast to strictly larger types.
The advantage in this solution for me was that it would check whether the python integers and floats fit into the dtype:
np.can_cast(42.0, np.float32) is True, whereas np.can_cast(type(42.0), np.float32) returns False, because python floats are 64-bit and in general the conversion will be lossy.

[LeonaTaric]

In all examples of the doc of np.can_cast, from_input can only be datatype、scalar or array scalar
when from_input is string, it will be converted as a datatype (such as "i8" -> np.int8)

I think it's an ENH but not a bug.

[LukasNickel]

But strings are scalars in numpy according to https://numpy.org/doc/stable/reference/generated/numpy.isscalar.html

[MatteoRaso]

It's possible that the author meant numerical scalar, although I can see the use of being able to check if a string can be casted to a numerical type.

[seberg]

It is what it is. I suspect the only good solution would be to add a new function can_cast_object(obj, dtype) or so.
Overloading API for objects and dtypes (similar to np.result_type also) just leads to terrible things like this (maybe we should even do that also for result type...). Proposals welcome ;).