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

[Robert Kern]

On Mon, Jan 14, 2013 at 1:04 AM, Nathaniel Smith <njs at pobox.com> wrote:
> 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

That's a statement about the policy for the stdlib, and just one
person's opinion. You, and numpy, are permitted to have a different
opinion.

In any case, I'm not strongly advocating for it. It's violation of
principle ("no fluent interfaces") is roughly in the same ballpark as
np.filled() ("not every two-liner needs its own function"), so I
thought I would toss it out there for consideration.

--
Robert Kern