<div dir="auto"><div>> <span style="font-family:sans-serif">In other words `np.arange<type(duck_array)>(1</span><span style="font-family:sans-serif">00)` (but</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">with a completely different syntax, probably hidden away only for</span><br style="font-family:sans-serif"><span style="font-family:sans-serif">libraries to use).</span></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">It sounds an bit like you're describing factory classmethods there. Is the solution to this problem to move (leaving behind aliases) `np.arange` to `ndarray.arange`, `np.zeros` to `ndarray.zeros`, etc - callers then would use `type(duckarray).zeros` if they're trying to generalize.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">Eric<br></font><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Sep 9, 2019, 21:18 Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net" target="_blank" rel="noreferrer">sebastian@sipsolutions.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2019-09-09 at 20:32 -0700, Stephan Hoyer wrote:<br>
> On Mon, Sep 9, 2019 at 6:27 PM Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com" rel="noreferrer noreferrer" target="_blank">ralf.gommers@gmail.com</a>><br>
> wrote:<br>
> > I think we've chosen to try the former - dispatch on functions so<br>
> > we can reuse the NumPy API. It could work out well, it could give<br>
> > some long-term maintenance issues, time will tell. The question is<br>
> > now if and how to plug the gap that __array_function__ left. It's<br>
> > main limitation is "doesn't work for functions that don't have an<br>
> > array-like input" - that left out ~10-20% of functions. So now we<br>
> > have a proposal for a structural solution to that last 10-20%. It<br>
> > seems logical to want that gap plugged, rather than go back and say<br>
> > "we shouldn't have gone for the first 80%, so let's go no further".<br>
> > <br>
> <br>
> I'm excited about solving the remaining 10-20% of use cases for<br>
> flexible array dispatching, but the unumpy interface suggested here<br>
> (numpy.overridable) feels like a redundant redo of __array_function__<br>
> and __array_ufunc__.<br>
> <br>
> I would much rather continue to develop specialized protocols for the<br>
> remaining usecases. Summarizing those I've seen in this thread, these<br>
> include:<br>
> 1. Overrides for customizing array creation and coercion.<br>
> 2. Overrides to implement operations for new dtypes.<br>
> 3. Overriding implementations of NumPy functions, e.g., FFT and<br>
> ufuncs with MKL.<br>
> <br>
> (1) could mostly be solved by adding np.duckarray() and another<br>
> function for duck array coercion. There is still the matter of<br>
> overriding np.zeros and the like, which perhaps justifies another new<br>
> protocol, but in my experience the use-cases for truly an array from<br>
> scratch are quite rare.<br>
> <br>
<br>
There is an issue open about adding more functions for that. Made me<br>
wonder if giving a method of choosing the duck-array whose<br>
`__array_function__` is used, could not solve it reasonably.<br>
Similar to explicitly choosing a specific template version to call in<br>
templated code. In other words `np.arange<type(duck_array)>(100)` (but<br>
with a completely different syntax, probably hidden away only for<br>
libraries to use).<br>
<br>
<br>
Maybe it is indeed time to write up a list of options to plug that<br>
hole, and then see where it brings us.<br>
<br>
Best,<br>
<br>
Sebastian<br>
<br>
<br>
> (2) should be tackled as part of overhauling NumPy's dtype system to<br>
> better support user defined dtypes. But it should definitely be in<br>
> the form of specialized protocols, e.g., which pass in preallocated<br>
> arrays to into ufuncs for a new dtype. By design, new dtypes should<br>
> not be able to customize the semantics of array *structure*.<br>
><br>
> (3) could potentially motivate a new solution, but it should exist<br>
> *inside* of select existing NumPy implementations, after checking for<br>
> overrides with __array_function__. If the only option NumPy provides<br>
> for overriding np.fft is to implement np.overrideable.fft, I doubt<br>
> that would suffice to convince MKL developers from monkey patching it<br>
> -- they already decided that a separate namespace is not good enough<br>
> for them.<br>
> <br>
> I also share Nathaniel's concern that the overrides in unumpy are too<br>
> powerful, by allowing for control from arbitrary function arguments<br>
> and even *non-local* control (i.e., global variables) from context<br>
> managers. This level of flexibility can make code very hard to debug,<br>
> especially in larger codebases.<br>
> <br>
> Best,<br>
> Stephan<br>
> <br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@python.org" rel="noreferrer noreferrer" target="_blank">NumPy-Discussion@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" rel="noreferrer noreferrer" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div></div>