ENH: pad: add delegation
#72
Conversation
lucascolley
force-pushed
the
pad-delegate
branch
from
f90cb78 to
d17fd2f
Compare
lucascolley
force-pushed
the
pad-delegate
branch
from
58ed3dc to
38690bb
Compare
|
@ev-br this is what I'm thinking. Of course, for only 1 function here this overcomplicates things, but I think we will see the benefits of cleanly separating which files are using the standard API and which are using library-specific functions, if/when more delegation is added. And it leaves the door open for more "smart" delegation if that would become appropriate. I'd like to leave this as draft until gh-53 is merged, as that PR adds a way to test with existing array libraries (and this one would cause merge conflicts anyway if we did that here first). |
There was a problem hiding this comment.
So the main points are:
- you effectively whitelist the kernels as opposed to a catch-all delegating to
xp.pad. An unknown backend will get a 'generic' implementation instead of being asked for apadnamespaced function. Makes sense. - the approach is way more light-touch than in scipy.{signal,ndimage,special}: in there you need either a delegation dict or a whole module. Here it's simple enough to keep the if-elif chain inside an affected function. Would be straightforward to refactor if a need arises.
A really minor point is the _delegators.py name: in scipy this only contains the _signature functions, and the kernels are elsewhere. Here this module contains the public symbol(s) including the if-elif delegation chains. This is fine though, and will also be simple to refactor if the need arises (that's a big fat if here).
My other inline comments are all optional and minor.
Concluding, this refactor LGTM.
| is_numpy_namespace, | ||
| is_torch_namespace, | ||
| ) | ||
| from ._lib._utils._typing import Array, ModuleType |
There was a problem hiding this comment.
Nit, optional: importing stdlib things from _utils three levels deep makes it look like there's something tricky on top of stdlib imports. I'd just import them as needed from stdlib.
There was a problem hiding this comment.
True for ModuleType, but since Array is "custom", I'd rather leave it like this I think. Then whenever we can start using things from array-api-typing, only that file needs to change.
EDIT: thinking that through, maybe we should have something like ArrayNamespace which can alias to ModuleType for now. But let's see how array-api-typing goes.
| # `array-api-compat` to override the import location | ||
|
|
||
| try: | ||
| from ...._array_api_compat_vendor import ( # pyright: ignore[reportMissingImports] |
closes gh-69