Note that an alternative idea discussed earlier was a separate function get_extension(), but IIRC that was not considered a good idea. Now that we have module-level __getattr__'s, it should not be a problem for any library to use a specified name like linalg or fft.

Whether the functions in the linalg extensions should all be required to exist or not was discussed in gh-403 (no clear conclusion there). One option discussed there to deal with hard to implement or more niche APIs is to create a separate status/label or some other way to track desired signatures (details to be worked out if we want to go that way).

Quoting @shoyer: My two cents is that it would be valuable if the standard specified the interface for these functions, even if not every library is going to implement them. It's really not a big deal to need to look up a compatibility table for advanced linear algebra functionality.

There is something to say for that as well (once we have a single easy to use compatibility table in a central place - see gh-402 and gh-462); I see both pros and cons. The pro is easy:

• having a signature & semantics defined for a larger set of functions is, over time, going to lead to fewer differences between libraries.

Concerns I have are:

• Scope management: until now it was relatively easy to draw a line about what included in the standard yes or no; this would make the scope significant wider (and that also implies more work I suspect),
• Spending a lot of time on existing mismatches for fairly niche functionality, e.g. see this comment for the matrix exponential function(s).
• We also do not do this for other functionality (e.g., most libraries have a median function, but we left it out on purpose because it's not great for distributed libraries; the median interface is not available anywhere in this repo).