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

[Skipper Seabold]

On Sun, Jan 13, 2013 at 6:39 PM, Nathaniel Smith <njs at pobox.com> wrote:

> 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...
>
>
I tend to agree with the notion that inplace operations shouldn't return
self, but I don't know if it's just because I've been conditioned this way.
Not returning self breaks the fluid interface pattern [1], as noted in a
similar discussion on pandas [2], FWIW, though there's likely some way to
have both worlds.

Skipper

[1] https://en.wikipedia.org/wiki/Fluent_interface
[2] https://github.com/pydata/pandas/issues/1893
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130113/29eb2a3b/attachment.html>