[Numpy-discussion] New numpy functions: filled, filled_like

[Nathaniel Smith]

On Sun, Jan 13, 2013 at 11:24 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Sun, Jan 13, 2013 at 6:27 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> Hi all,
>>
>> PR 2875 adds two new functions, that generalize zeros(), ones(),
>> zeros_like(), ones_like(), by simply taking an arbitrary fill value:
>>   https://github.com/numpy/numpy/pull/2875
>> So
>>   np.ones((10, 10))
>> is the same as
>>   np.filled((10, 10), 1)
>>
>> The implementations are trivial, but the API seems useful because it
>> provides an idiomatic way of efficiently creating an array full of
>> inf, or nan, or None, whatever funny value you need. All the
>> alternatives are either inefficient (np.ones(...) * np.inf) or
>> cumbersome (a = np.empty(...); a.fill(...)). Or so it seems to me. But
>> there's a question of taste here; one could argue instead that these
>> just add more clutter to the numpy namespace. So, before we merge,
>> anyone want to chime in?
>
> One alternative that does not expand the API with two-liners is to let
> the ndarray.fill() method return self:
>
>   a = np.empty(...).fill(20.0)

This violates the convention that in-place operations never return
self, to avoid confusion with out-of-place operations. E.g.
ndarray.resize() versus ndarray.reshape(), ndarray.sort() versus
np.sort(), and in the broader Python world, list.sort() versus
sorted(), list.reverse() versus reversed(). (This was an explicit
reason given for list.sort to not return self, even.)

Maybe enabling this idiom is a good enough reason to break the
convention ("Special cases aren't special enough to break the rules. /
Although practicality beats purity"), but it at least makes me -0 on
this...

(The nice thing about np.filled() is that it makes np.zeros() and
np.ones() feel like clutter, rather than the reverse... not that I'm
suggesting ever getting rid of them, but it makes the API conceptually
feel smaller, not larger.)

-n