Unfortunately, supporting Python scalars is tricky (I would love to do it, but I am not sure how to define "safe" for it).

However, right now it actually fails NumPy scalars as well! Which it of course shouldn't even if I think passing in scalar.dtype is preferable.

Thanks @ev-br for pointing out this issue.

About supporting Python scalars, ufuncs currently effectively use same-kind casting by default after promotion and then trust that the coercion/conversion step will fail e.g. for int8(1000).
That is one can argue that can_cast(1000, int8) is "same-kind", but not "safe". But is can_cast(0, int8) safe? Maybe actually more complicated is can_cast(0., float32) safe or same-kind?

The other view is that can_cast is used for "promotion" like logic (e.g. cupy uses it for promotion) where can_cast(1000, int8) should be considered safe because we will try it (but fail!).