FEATURE: add `partial` (args/kwargs) field to Action?

[tlambert03]

Should we add the ability store args/kwargs (like a partial) in an Action?

    action1 = Action(id="cmd_id", title="title1", callback=cb)
    action2 = Action(id="cmd_id2", title="title2", callback=cb, kwargs={"a": 1})

or should the callback just be the partial. Need to think about pros cons.
first thought: the "pro" of just using callback=partial(cb, a=1) is that it's familiar regular python. The "con" is that it (currently) would require us to create a new command id for every partial variant. Maybe that's not a big deal

[Czaki]

Yes, we should add this. It will allow writing much cleaner code and avoid leaking memory.

[lucyleeow]

We discussed this recently and @Czaki was in favour of this and NOT partial (was there concern on the use of partials in loop/nested functions?).

@tlambert03 are you happy to take a PR to add kwarg field to Action ?

[tlambert03]

I suspect the concert is strong refs inside the partial, is that true @Czaki?

If so, it implies that the "proper" solution here would need to consider or reimplement all of the weak referencing stuff in psygnal.

@lucyleeow i would definitely appreciate and consider a PR. Id say let's start with the simple/direct approach, not worrying about weakrefs, and see how it generally looks and feels

[Czaki]

I suspect the concert is strong refs inside the partial, is that true @Czaki?

Strong ref, harder debugging, less control. Promoting of bad patterns (not all callbacks are as good, prepared for partial like psygnal).

If so, it implies that the "proper" solution here would need to consider or reimplement all of the weak referencing stuff in psygnal.

I think that we may start with a simple dict, but limit usage to basic types like str, int, float

And I'm not sure if such advanced things like in psygnal are required. As actions are global, how we expect to hardcode short living objects bind to Action.

Or is there an obvious use case for short living actions?

[tlambert03]

Or is there an obvious use case for short living actions?

Nope I'm happy to consider these as long lived objects and just use a simple dict

[lucyleeow]

Revisiting things, could someone clarify, if we are limiting kwargs to basic types, how would this fix the strong refs inside partial problem?

i.e., would passing an int via partial(cb, a=1) be better than Action(id="cmd_id2", title="title2", callback=cb, kwargs={"a": 1}) ?

Or is the improvement here in regards to action kwargs being neater and the code thus easier to debug? Also I am not clear what you mean by partials providing "less control" @Czaki?

Also if we were to implement action kwargs, would we use a partial e.g., partial(self.resolved_callback, **kwargs) here:

app-model/src/app_model/registries/_commands_reg.py

Line 76 in e8fb729

return self._injection_store.inject(self.resolved_callback, processors=True)

or would you pass the kwargs when we execute the callback in Store.inject in in-n-out ?

Thanks

cc @tlambert03

[Czaki]

Revisiting things, could someone clarify, if we are limiting kwargs to basic types, how would this fix the strong refs inside partial problem?

Because we do not worry about keeping reference to a string or float object. We worry about keeping reference to big object's live viewer or big numpy array.

i.e., would passing an int via partial(cb, a=1) be better than Action(id="cmd_id2", title="title2", callback=cb, kwargs={"a": 1}) ?

I, personally, prefer kwargs as an action parameter, as it makes debugging easier. There will be no need to deal with inspecting partial.

Also, I expect that people are looking to napari codebase for inspiration. And they may not notice subtle difference and use partial/lambdas as signal callback, that may lead to storing hard references to problematic objects and even segfaults.

or would you pass the kwargs when we execute the callback in Store.inject in in-n-out ?

I think that we should update in-n-out and pass kwargs directly.

[lucyleeow]

To clarify, if we were to expand kwargs to take complex objects (e.g., window/widgets) we would pass them safely: use a weak ref when passing to Action and before passing to the action callback we would unpack the weak ref?

cc @Czaki

[Czaki]

To clarify, if we were to expand kwargs to take complex objects (e.g., window/widgets) we would pass them safely: use a weak ref when passing to Action and before passing to the action callback we would unpack the weak ref?

We expect to not pass complex objects. We expect to pass int, str, Enum, float etc.
We expect that actions are created on import time, and in such situation, the complex object should not be created.

[lucyleeow]

Ah okay there is never an intention of passing more complex objects.