On Mon, Jun 3, 2019 at 7:56 PM Sebastian Berg <sebast...@sipsolutions.net> wrote:
> On Sun, 2019-06-02 at 08:42 +0200, Ralf Gommers wrote: > > > > > <snip> > > > > > > > > > > This sounds like a restructuring or factorization of the API, in > > > order to make it smaller, and thus easier to learn and use. > > > It may start with the docs, by paying more attention to the "core" > > > or important functions and methods, and noting the deprecated, or > > > not frequently used, or not important functions. This could also > > > help the satellite projects, which use NumPy API as an example, and > > > may also be influenced by them and their decisions. > > > > > > > Indeed. It will help restructure our docs. Perhaps not the reference > > guide (not sure yet), but definitely the user guide and other high- > > level docs we (or third parties) may want to create. > > > > Trying to follow the discussion, there seems to be various ideas? Do I > understand it right that the original proposal was much like doing a > list of: > > * np.ndarray.cumprod: low importance -> prefer np.multiply.accumulate > * np.ravel_multi_index: low importance, but distinct feature > Indeed. Certainly no more than that was my idea. > Maybe with added groups such as "transpose-like" and "reshape-like" > functions? > This would be based on 1. "Experience" and 2. usage statistics. This > seems mostly a task for 2-3 people to then throw out there for > discussion. > There will be some very difficult/impossible calls, since in the end > Nathaniel is right, we do not quite know the question we want to > answer. But for a huge part of the API it may not be problematic? > Agreed, won't be problematic. > > Then there is an idea of providing better mixins (and tests). > This could be made easier by the first idea, for prioritization. > Although, the first idea is probably not really necessary to kick this > off at all. The interesting parts to me seem likely how to best solve > testing of the mixins and numpy-api-duplicators in general. > > Implementing a growing set of mixin seems likely fairly straight > forwrad (although maybe much easier to approach if there is a list from > the first project)? Indeed. I think there's actually 3 levels here (at least): 1. function name: high/low importance or some such simple classification 2. function signature and behavior: is the behavior optimal, what would be change, etc. 3. making duck arrays and subclasses that rely on all those functions and their behavior easier to implemement/use Mixins are a specific answer to (3). And it's unclear if they're the best answer (could be, I don't know - please don't start a discussion on that here). Either way, working on (3) will be helped by having a better sense of (1) and (2). Also think about effort: (2) is at least an order of magnitude more work than (1), and (3) likely even more work than (2). > And, once we have a start, maybe we can rely on the > array-like implementors to be the main developers (limiting us mostly > to review). > > > The last part would be probably for users and consumers of array-likes. > This largely overlaps, but comes closer to the problem of "standard". > If we have a list of functions that we tend to see as more or less > important, it may be interesting for downstream projects to restrict > themselves to simplify interoperability e.g. with dask. > > Maybe we do not have to draw a strict line though? How plausible would > it be to set up a list (best auto-updating) saying nothing but: > > `np.concatenate` supported by: dask, jax, cupy > That's probably not that hard, and I agree it would be quite useful. The namespaces of each of those libraries is probably not the same, but with dir() and some strings and lists you'll get a long way here I think. > > I am not sure if this is helpful, but it feels to me that the first > part is what Ralf was thinking of? Just to kick of such a a "living > document". Indeed. I could maybe help with providing the second pair of eyes > for a first iteration there, Ralf. Awesome, thanks Sebastian. Cheers, Ralf The last list I would actually find > interesting myself, but not sure how easy it would be to approach it? > > Best, > > Sebastian > > > > Ralf > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
