[Numpy-discussion] numpy.filled, again

[Robert Kern]

On Wed, Jun 12, 2013 at 1:47 PM, Daniele Nicolodi <daniele at grinta.net> wrote:
> On 12/06/2013 14:29, Robert Kern wrote:
>> On Wed, Jun 12, 2013 at 1:26 PM, Daniele Nicolodi <daniele at 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