Validate dependencies in constructor

[philippjfr]

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.

• Fixes No error raised when a method depends on Parameterized instances set after calling super() #566
• Add test(s)

[maximlt]

I see that the error is not raised at class creation time but on instantiation and only when watch=True, it's a big improvement anyway.

[philippjfr]

It cannot be done at class creation time because the class cannot know what happens in the constructor before super is called.

[maximlt]

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'>.

[philippjfr]

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.

[maximlt]

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.