On Sat, Nov 4, 2017 at 6:47 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote:
> > You just summarized excellently why I'm on a quest to change `asarray` > to `asanyarray` within numpy +1 -- we should all be using asanyarray() most of the time. However a couple notes: asarray() pre-dates asanyarray() by a LOT. asanyarray was added to better handle subclasses, but there is a lot of legacy code out there. An legacy coders -- I know that I still usually use asarray without thinking about it -- sorry! Obviously, this covers only ndarray > subclasses, not duck types, though I guess in principle one could use > the ABC registration mechanism mentioned above to let those types pass > through. > The trick there is that what does it mean to be duck-typed to an ndarray? For may applications its' critical that the C API be the same, so duck-typing doesn't really apply. And in other cases, in only needs to support a small portion of the numpy API. IS essence, there are an almost infinite number of possible ABCs for an ndarray... For my part, I've been known to write custom "array_like" code -- it checks for the handful of methods I know I need to use, and tI test it against the small handful of duck-typed arrays that I know I want my code to work with. Klunky, and maybe we could come up with a standard way to do it and include that in numpy, but I'm not sure that ABCs are the way to do it. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
