Hi Stephan, Another part of your reply worth considering, though slightly off topic for the question here, of what to pass on in `types`:
On Sun, Nov 4, 2018 at 7:51 PM Stephan Hoyer <sho...@gmail.com> wrote: > On Sun, Nov 4, 2018 at 8:03 AM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> I thought of this partially as I was wondering how an implementation for >> ndarray itself would look like. For that, it is definitely useful to know >> all unique types, since if it is only ndarray, no casting whatsoever needs >> to be done, while if there are integers, lists, etc, an attempt has to be >> made to turn these into arrays >> > > OK, so hypothetically we could invoke versions of each the numpy function > that doesn't call `as[any]array`, and this would slightly speed-up > subclasses that call super().__array_function__? > > A longer-term goal that I had in mind here was generally for the implementations to just be able to assume their arguments are ndarray, i.e., be free to assume there is a shape, dtype, etc. That is not specifically useful for subclasses; for pure python code, it might also mean array mimics could happily use the implementation. But perhaps more importantly, the code would become substantially cleaner. Anyway, really a longer-term goal... All the best, Marten
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
