Closed philippjfr closed 1 year ago
It cannot be done at class creation time because the class cannot know what happens in the constructor before super is called.
Is it because we allow people depending on objects that aren't declared as Parameter
but are set in the __init__
? If so, I'd be happy to see a warning in cases like that, it's a bit of an anti-pattern isn't it?
A recent change made this fail when watch=False
:
import param
class P(param.Parameterized):
x = param.Parameter()
@param.depends('y')
def debug(self): pass
Traceback:
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
Cell In[42], line 3
1 import param
----> 3 class P(param.Parameterized):
4 x = param.Parameter()
6 @param.depends('y')
File ~/dev/param/param/parameterized.py:3097, in ParameterizedMetaclass.__init__(mcs, name, bases, dict_)
3094 on_init = dinfo.get('on_init', False)
3095 minfo = MInfo(cls=mcs, inst=None, name=name,
3096 method=method)
-> 3097 deps, dynamic_deps = _params_depended_on(minfo, dynamic=False)
3098 if watch:
3099 _watch.append((name, watch == 'queued', on_init, deps, dynamic_deps))
File ~/dev/param/param/parameterized.py:649, in _params_depended_on(minfo, dynamic, intermediate)
647 dinfo = getattr(minfo.method, "_dinfo", {})
648 for d in dinfo.get('dependencies', list(minfo.cls.param)):
--> 649 ddeps, ddynamic_deps = (minfo.cls if minfo.inst is None else minfo.inst).param._spec_to_obj(d, dynamic, intermediate)
650 dynamic_deps += ddynamic_deps
651 for dep in ddeps:
File ~/dev/param/param/parameterized.py:2661, in Parameters._spec_to_obj(self_, spec, dynamic, intermediate)
2659 return [], [] if intermediate == 'only' else [DInfo(spec=spec)]
2660 else:
-> 2661 raise AttributeError(f"Attribute {attr!r} could not be resolved on {src}.")
2663 if obj is None or not intermediate:
2664 return [info], []
AttributeError: Attribute 'y' could not be resolved on <class '__main__.P'>.
I'm a little on the fence on it and likely have to revert your change. I've seen many people use the pattern and I have also used it on occasion because declaring parameters is sometimes awkward, e.g. often I use parameters for public API declarations but internally I want to be able to set up dependencies on static attributes and not have to set up parameter declarations.
I use parameters for public API declarations but internally I want to be able to set up dependencies on static attributes and not have to set up parameter declarations.
Yes that's a weakness of Param that has no way to tell whether a parameter is an input or some state you compute later on. Param has @output
but I haven't seen that used much. dataclasses.field
has an init
that is True
by default and that you can use to indicate whether the generated init
should contain this field, I think Param should have something similar.
The dynamic resolution of dependencies loosened the validation for dependencies. However this was only intended to allow dynamic dependency resolution of the leafs or branches of nested dependencies, i.e. the root of a nested dependency has to be declared. This adds validation to ensure that the root dependency can be resolved and adds an error otherwise.