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

[Nathaniel Smith]

On Sun, Jan 13, 2013 at 11:48 PM, Skipper Seabold <jsseabold at gmail.com> wrote:
> 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.

Ah-hah, here's the email where Guide officially proclaims that there
shall be no "fluent interface" nonsense applied to in-place operators
in Python, because it hurts readability (at least for Dutch people
;-)):
  http://mail.python.org/pipermail/python-dev/2003-October/038855.html

-n