-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ToDos from meeting on 22 Sep 2021 #1
Comments
There are two other points we didn't get to in the meeting:
@jthielen perhaps you want to open issues for those two as well? |
I've finally gotten to putting together these writeups (see #3, #4, #5, and #6). I tried to summarize things as thoroughly and as neutrally as possible, but I probably missed a thing or two, and almost certainly some of my opinion slipped in! So please feel free to correct/discuss/improve upon any of the summaries as well as discuss the issues at hand. |
Excellent - thank you very much both of you (and for all the extra credit issues you added @jthielen !) I'm going to close this now in favour of all those other issues. |
Our meeting notes from today have a few ToDos, which I'm now going to assign to people. Each of these are for the tagged person to open a corresponding issue in this repo with more details for further discussion of that topic.
Defining pairwise interactions - @jthielen
We need to discuss how pairwise interactions between different libraries are defined, because a purely linear (or linked-list-like) approach like
__array_priority__
is not sufficient for an interaction problem that is better defined as a directed acyclic graph. There are a few notes on this from the meeting, including a mention of NEP37, but another suggestion was that we might need to make a special repo which contains only the "official" hierarchy, which other libraries would then import. That way there cannot be inconsistencies, and any conflicts have to be resolved publicly and in the same place.Consistency of type deferral - @jthielen
We have a similar problem with type deferral (e.g., between array functions, ufuncs, module functions, construction, and binary ops). Every library needs to have a way to say "here's how I defer to another library", and the approach needs to be welcoming to any new array-like libraries that try to enter the ecosystem.
Nested array reprs - @hameerabbasi
The problem of ensuring that reprs of nested duck arrays still legibly display key information from all the wrapped array types has been discussed in reprs of nested duck arrays dask/dask#6637 for example. @hameerabbasi had a suggestion for an implementation involving constructing a dict with key info from each wrapped array, which deserves to be fleshed out in its own issue.
Once all 3 of these issues are opened I will close this one.
The text was updated successfully, but these errors were encountered: