On Monday, July 23, 2012, OC wrote:
It's unPythonic just in the sense that it is unlike every other type
constructor in Python. int(x) returns an int, list(x) returns a list,
but np.complex64(x) sometimes returns a np.complex64, and sometimes it
returns a np.ndarray, depending on what 'x' is.
This object factory design pattern adds useful and natural functionality.
I can see an argument for deprecating this behaviour altogether and
referring people to the np.asarray(x, dtype=complex) form; that would
be cleaner and reduce confusion. Don't know if it's worth it, but
that's the only cleanup that I can see even being considered for these
constructors.
From my experience in teaching, I can tell that even beginners have no
problem with the fact that complex128(1) returns a scalar and that
complex128(r_[1]) returns an array. It seems to be pretty natural.
Also, from the duck-typing point of view, both returned values are
complex, i.e. provide 'real' and 'imag' attributes and 'conjugate()'
method.
On the contrary a real confusion is with numpy.complex acting
differently than the other numpy.complex*.
People do write from numpy import *
Yeah, that's what I do very often in interactive ipython sessions.
Other than this, people are warned often enough that this shouldn't be
used in real programs.
Don't be so sure of that. The pylab mode from matplotlib has been both a
blessing and a curse. This mode is very popular and for many, it is all
they need/want to know. While it has made the transition from other
languages easier for many, the polluted namespace comes at a small cost.
And it is only going to get worse when moving over to py3k where just about
everything is a generator. __builtin__.any can handle generators, but
np.any does not. Same goes for several other functions.
Note, I do agree with you that the discrepancy needs to be fixed, I just am
not sure which way.
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
