Thank you for your answers. Chris Barker wrote: > for consistency with the rest of the numpy types
Then, why do "numpy.complex64(A)", "numpy.complex128(A)", "numpy.uint8(A)",... all work with arrays? It's very convenient that it works like this! It's awkward that "numpy.complex(A)" is the only one that does not. Is there a problem to extend "numpy.complex" so that it acts the same as "numpy.complex64"? Pauli Virtanen wrote: > Remember that "numpy.complex", "numpy.complex64" (...) are types that > represent scalar numbers, not arrays. (...) That you get an array > out from "numpy.complex64(A)" rather than a "ValueError" is > un-Pythonic. Thanks for pointing this out. I don't see why it would be un-pythonic, and on the contrary this behavior is useful. Why shouldn't a "type" object offer such useful method/constructor? Is there a design mistake here? (from the Python point of view, not from the C++ point of view). All the types you mention inherit from "numpy.generic", except "numpy.complex". Is there a reason for this? I find it awkward and misleading. I understand that "numpy.real" and "numpy.complex" are different things from a programmer's point of view, the first being a "function" and the latter being a "type". However, from the syntax point of view, I think that an average user is founded to believe that they behave similarly with arrays. And such an improvement seems to be easy. For example, why isn't "numpy.complex" simply equal to "numpy.complex_" instead of "__builtin__.complex"? Note: same remark for "numpy.bool" and "numpy.bool_" _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
