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
{{ message }}
Repository navigation
Add way to pass backend specific arguments (optionally?) #40
Note that backend_kwargs={"name": ...} is not actually the user interface-- the function call/signature is modified in the dispatchable decorator (see here). So users pass keyword arguments directly in the call, not as a dictionary, in networkx.
It might also make sense to include an explicit optional backend= argument for clarity, since different backends may have distinct optional parameters. From a readability standpoint, something like
foo(x, y, backend="backend1", backend1_arg1="..", backend1_arg2="...")
is clearer than
foo(x, y, backend1_arg1="..", backend1_arg2="...")
as it makes the backend to which these additional args belong to explicit in the user code.
Alternatively, we could add additional backend arguments for all backends via backend_kwargs={"name": ...} in the backend_opts context manager (to stay context-manager-oriented in the user API), where the name is the name of the backend and the value is the dictionary of that backend's additional args and their values. However, that might not be ideal, since additional backend arguments are often call-specific rather than context-specific, and each function could have different additional backend args.
LMKWYT. also i can work on this, if you have not already started working on this and/or would like to work on this.
Ah OK, so a naming convention. I was thinking that you can have foo(..., backend1_arg=..., backend2_arg=...) in principle, i.e. you may not actually know which backend is used, but if that backend is used you want a specific argument to be used.
The naming convention seems like a harder sell, although I am not sure it is actually anything more. All unknown kwargs are passed only to the backend if they match the naming scheme...
(Backends with an _ in the name could be funky, but it's OK so long as there isn't another backend that starts the same.)
Alternatively, we could add additional backend arguments for all backends via backend_kwargs={"name": ...} in the backend_opts context manager
If the options are generic to the backend (e.g. resource use or so), then that may be a nicer way actually. If they are specific to the function that seems a bit awkward.
I didn't have a big need right now, just remembered this, so I am not sure what is actually the bigger use-case to solve?
Another way--that we have a PR for in networkx--is to allow <backend>_kwargs keyword argument. See networkx/networkx#7297 . This way, you can extract the backend name by first matching .endswith("_kwargs").
I'm curious what y'all think. My bandwidth is very limited atm, but I may have a couple minutes here and there to read and chime in 😁
Ah, yeah, that may be a good middle-ground in terms of being quite clear with a <name>_kwargs scheme while somewhat less of a dance (I might go bikeshed towards <name>_options, even if they are then passed as kwargs).
I remembered this and opened the issue (I think also because it was mentioned in issue #1). I think I need to actually understand the use-case a bit more.
That is I don't mind adding support, but I think it needs to be opt-in (for the library) for now. And the other thing is that it may be that global options are actually more interesting.
(I.e. device config or so, rather than a specific algorithmic choice).
(Right now backends don't have to be valid identifiers I think, but that seems OK in the end, they should be normally anyway.)
Yeah, I don't have a strong opinion here. Note that the NetworkX PR has been open for 21 months now, so this isn't particularly urgent--no user has asked for it yet.
But, yeah, anything that modifies the function signature should probably be opt-in for now. The scikit-image team wanted to begin with minimally-invasive dispatching, which included not changing signatures. Opt-in may also allow for choosing which particular method to use.
Also, +1 for advancing global options. This seems to keep coming up.
And, yeah, if backend names aren't valid identifiers, then it should be fine, but they may miss out on some "sugar" such as <name>_options--their choice.
Activity
Schefflera-Arboricola commentedon Nov 5, 2025
Note that
backend_kwargs={"name": ...}is not actually the user interface-- the function call/signature is modified in thedispatchabledecorator (see here). So users pass keyword arguments directly in the call, not as a dictionary, in networkx.It might also make sense to include an explicit optional
backend=argument for clarity, since different backends may have distinct optional parameters. From a readability standpoint, something likeis clearer than
as it makes the backend to which these additional args belong to explicit in the user code.
Alternatively, we could add additional backend arguments for all backends via
backend_kwargs={"name": ...}in thebackend_optscontext manager (to stay context-manager-oriented in the user API), where the name is the name of the backend and the value is the dictionary of that backend's additional args and their values. However, that might not be ideal, since additional backend arguments are often call-specific rather than context-specific, and each function could have different additional backend args.LMKWYT. also i can work on this, if you have not already started working on this and/or would like to work on this.
seberg commentedon Nov 5, 2025
Ah OK, so a naming convention. I was thinking that you can have
foo(..., backend1_arg=..., backend2_arg=...)in principle, i.e. you may not actually know which backend is used, but if that backend is used you want a specific argument to be used.The naming convention seems like a harder sell, although I am not sure it is actually anything more. All unknown kwargs are passed only to the backend if they match the naming scheme...
(Backends with an
_in the name could be funky, but it's OK so long as there isn't another backend that starts the same.)If the options are generic to the backend (e.g. resource use or so), then that may be a nicer way actually. If they are specific to the function that seems a bit awkward.
I didn't have a big need right now, just remembered this, so I am not sure what is actually the bigger use-case to solve?
eriknw commentedon Nov 6, 2025
Another way--that we have a PR for in networkx--is to allow
<backend>_kwargskeyword argument. See networkx/networkx#7297 . This way, you can extract the backend name by first matching.endswith("_kwargs").I'm curious what y'all think. My bandwidth is very limited atm, but I may have a couple minutes here and there to read and chime in 😁
seberg commentedon Nov 6, 2025
Ah, yeah, that may be a good middle-ground in terms of being quite clear with a
<name>_kwargsscheme while somewhat less of a dance (I might go bikeshed towards<name>_options, even if they are then passed askwargs).I remembered this and opened the issue (I think also because it was mentioned in issue #1). I think I need to actually understand the use-case a bit more.
That is I don't mind adding support, but I think it needs to be opt-in (for the library) for now. And the other thing is that it may be that global options are actually more interesting.
(I.e. device config or so, rather than a specific algorithmic choice).
(Right now backends don't have to be valid identifiers I think, but that seems OK in the end, they should be normally anyway.)
eriknw commentedon Nov 16, 2025
Yeah, I don't have a strong opinion here. Note that the NetworkX PR has been open for 21 months now, so this isn't particularly urgent--no user has asked for it yet.
But, yeah, anything that modifies the function signature should probably be opt-in for now. The scikit-image team wanted to begin with minimally-invasive dispatching, which included not changing signatures. Opt-in may also allow for choosing which particular method to use.
Also, +1 for advancing global options. This seems to keep coming up.
And, yeah, if backend names aren't valid identifiers, then it should be fine, but they may miss out on some "sugar" such as
<name>_options--their choice.