On Mon, Apr 15, 2019 at 4:39 PM Stephan Hoyer <sho...@gmail.com> wrote: > > On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith <n...@pobox.com> wrote: >> >> What's the difference between >> >> np.concatenate.__numpy_implementation__(...) >> >> and >> >> np.ndarray.__array_function__(np.concatenate, ...) >> >> ? > > > I can answer this technically, though this doesn't seem to be quite what > you're looking for: > - The former always succeed at dispatch, because it coerces all arguments to > NumPy arrays. > - The second will either return NotImplemented (if a non-NumPy arrays > implements __array_function__), or give the same result as former. > >> >> More generally, I guess I'm not quite clear on how to think about what the >> "no dispatch" version does, because obviously it doesn't make sense to have >> *no* dispatch. Instead it's something like "the legacy hard-coded dispatch"? > > __numpy_implementation__ means you skip __array_function__ dispath and call > the original NumPy function. In practice, this means you get legacy > hard-coded dispatch behavior in most cases, e.g., the result will always be > in the form of NumPy array(s). > > It doesn't mean that the implementation always coerces all arguments to NumPy > arrays. For example, np.result_type() will pull out of .dtype attributes off > of its arguments, even without necessarily coercing its arguments to NumPy > arrays. This strange version of "the implementation for NumPy arrays" turns > out to be something that several libraries that want to implement > __array_function__ want to be able to continue to use on their own array > objects (namely, JAX and CuPy).
Microsoft's "open standard" [1] document format, OOXML, famously contains tags like "autoSpaceLikeWord95" and "useWord97LineBreakRules". If you want to correctly interpret a Word document, you have to know what these mean. (Unfortunately, the standard doesn't say.) Mostly I would like the definition for numpy 1.17's semantics to be internally coherent and self-contained. If the documentation for __numpy_implementation__ is just "it does whatever numpy 1.14 did", then that seems not so great. Is there any way to define __numpy_implementation__'s semantics without incorporating previous versions of numpy by reference? -n [1] https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
