On Sun, Jan 13, 2013 at 11:48 PM, Skipper Seabold <jsseab...@gmail.com> wrote: > 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.
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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
