On Sun, Jan 13, 2013 at 6:39 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Sun, Jan 13, 2013 at 11:24 PM, Robert Kern <robert.k...@gmail.com> > wrote: > > On Sun, Jan 13, 2013 at 6:27 PM, Nathaniel Smith <n...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
