On Wed, Jun 12, 2013 at 1:47 PM, Daniele Nicolodi daniele@grinta.net wrote:
On 12/06/2013 14:29, Robert Kern wrote:
On Wed, Jun 12, 2013 at 1:26 PM, Daniele Nicolodi daniele@grinta.net wrote:
There where the additional proposal (mostly neglected on the original thread) to add the 'fill' optional parameter to the array constructor:
np.ndarray(shape, fill=value)
has an obvious meaning to me.
I also don't really see why an np.empty() constructor exists, it seems to do the same thing that np.ndarray() does.
It predates numpy and the numpy.ndarray type.
I see, but I'm surprised by the fact that np.empty() is not an alias for np.ndarray() neither is implemented in term of np.ndarray().
Since the constructor exists and it would be the "most pythonic" way of constructing an ndarray object I don't see why it's usage should not be encouraged.
However, I don't know if adding a np.ndarray_like() constructor would make much sense.
Also that.
I don't understand if you are saying that adding the fill parameter to np.ndarray() is a good or a bad idea.
My point there was that the ones()/ones_like(), zeros()/zeros_like() pairings are useful and extending that to empty()/empty_like() is a good thing. Dropping empty() in favor of ndarray() breaks that symmetry, and ndarray_like() doesn't make sense as a name.
If it is a bad idea, what are the drawbacks compared to the other two proposed solutions?
I think it has more drawbacks than the others. ndarray() is quite low-level. There is very little intelligence in it, which is a good thing. It is used in places where that low-level capability is necessary, e.g. in the memmap implementation where it is constructing an ndarray object that points to specific memory. array(), empty_like(), ones(), etc. are relatively high level and have more intelligence built into them. The "filled" functionality, however you spell it, is part of the latter category. Implementing it in the low level part interferes with ndarray()'s current low-level uses. You *could* drop the current empty() in favor ndarray() if you wanted to as empty() is not so smart and the defaults for the other ndarray() arguments are sensible. But if you extend the functionality of empty() to implement filled(), then that no longer holds.
-- Robert Kern