You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.