param
param copied to clipboard
on_init should only trigger if the parameter is set in the constructor
My hope when suggesting #513 was that a parameter would be triggered if it were passed into the constructor. It appears that the on_init
argument always triggers on init regardless of whether the parameter was passed or not.
In the following example when Test
is instantiated without any arguments then it still triggers the method that depends on s
.
I think it should work equivalent to this:
def __init__(self, **params):
super().__init__(**params)
if 's' in params:
self.param.trigger('s')
It may be useful to always trigger a method on initialization, but since that behavior is independent of any parameters then it should be a separate decorator that isn't associated with parameters. For example:
class Test(param.Parameterized):
s = param.String(default='default')
@param.on_init
def run_on_initialization(self):
print(self.s)
Having the on_init
argument in the depends
decorator makes it seem like it is associated with the parameters that are also passed in to the depends
decorator. Currently it's not, but I think it should be.
I think on_init
is correctly implemented as independent of any parameter or argument passing; it was designed to cover the case where some parameter values would be undefined unless the method gets invoked, and shouldn't depend on what the user may or may not have passed in the constructor. It's true that it could be a separate decorator, but then we'd have to document and make people aware of that separate decorator, and I think it's easier to tell people to just examine the options available for param.depends
and select the behavior you want.
That said, I think you're right that there is functionality missing here, and I think it's what you originally pointed out in #513, i.e. that when a user passes in a parameter to the constructor, that should trigger the method getting called, even if on_init=False
. I think that's a valid bug report and at a semantic level, I think the method should get triggered (and should always have gotten triggered) when such values were specified, independently of any setting of on_init
(which is largely for different purposes). I'm not sure if it's safe to make that change now, but I'd guess the typical worst outcome of doing so would be to have the method invoked unnecessarily many times? If that's a problem, we could add a new keyword on_argument
, which invokes the method specifically in the case that an argument for the indicated parameter values is supplied in the constructor. But I'd support making one of those two fixes.
@philippjfr are there any remaining functionalities needed after #620? Or can we close this?
@philippjfr, can you please clarify the status of #620 -- is it sufficient to address this issue? Only partial? To be abandoned?