[enhancement] catch and error on unsized numpy types

[AlexanderWeyman]

While writing some code examples to become more familiar with pycuda, I figured out that there seems to be an issue with pycuda.driver.Function.prepare. Hoping that this is helpful, I attached an example that demonstrates, how prepare() makes a difference between passing np.complex and np.complex128 as the expected data type (same for np.float and np.float64) multiply_prepared.py.txt

My guess is that this problem traces back to checking np.number in arg_type.mro

For clarity, here a snippet extracted from function_prepare() in driver.py:

>>> import numpy as np

>>> 
>>> arg_types = [np.complex, np.complex64, np.complex128, np.float, np.float32, np.float64]
>>> arg_format = ""
>>> 
>>> for i, arg_type in enumerate(arg_types):
...     if (isinstance(arg_type, type)
...             and np is not None and np.number in arg_type.__mro__):
...         arg_format += np.dtype(arg_type).char
...     elif isinstance(arg_type, str):
...         arg_format += arg_type
...     else:
...         arg_format += np.dtype(np.uintp).char
... 
>>> print(arg_format)
LFDLfd

In my understanding the output should be more like "DFDdfd" since

>>> np.dtype(np.complex).type
<class 'numpy.complex128'>
>>> np.dtype(np.float).type
<class 'numpy.float64'>

Best

[inducer]

Numpy does not document the np.float and np.complex types as something that can be instantiated: https://docs.scipy.org/doc/numpy/user/basics.types.html. As such, it seems more like undefined behavior that you're able to do so. I'd be happy to take a patch that raises an error if someone tries passing these (unsized!) objects to a kernel. But even without that message, I would already consider it ill-formed.