Decorator madness

[willmcgugan]

Decorators for watch, compute, and validate. Works like this:

class MyWidget(Widget):

    count = reactive(0)
    double_count = reactive(0)

    @count.watch
    def count_changed(self, new_count:int):
        ...

    @count.validate
    def _max_ten(self, value:int) -> int:
        return min(10, value)

    @double_count.compute
    def _double(self) -> int:
        return self.count * 2

[rodrigogiraoserrao]

I'm excited for these changes but I think there are a couple of loose ends we must tie before merging.

[rodrigogiraoserrao]

We're missing, at least, a test that makes sure that init=False in the watch decorator is respected.

[rodrigogiraoserrao]

Suggested change

	In addition to the the naming convention, you can also define a validate method via a decorator.
	In addition to the naming convention, you can also define a validate method via a decorator.

[rodrigogiraoserrao]

Suggested change

	The following example uses a computed attribute. It displays three inputs for each color component (red, green, and blue). If you enter numbers into these inputs, the background color of another widget changes.
	The following example uses a computed attribute. It displays one input for each color component (red, green, and blue). If you enter numbers into these inputs, the background color of another widget changes.

Suggested change

	The following example uses a computed attribute. It displays three inputs for each color component (red, green, and blue). If you enter numbers into these inputs, the background color of another widget changes.
	The following example uses a computed attribute. It displays three inputs, one for each color component (red, green, and blue). If you enter numbers into these inputs, the background color of another widget changes.

[rodrigogiraoserrao]

Suggested change

	The following examples replaces the naming convention with an equivalent decorator:
	The following example replaces the naming convention with an equivalent decorator:

[rodrigogiraoserrao]

I think I do have a suggestion.
The decorators (Watch / Compute / Validate) shouldn't be generic over the type of the method they're decorating; rather, they should be generic over the type of the reactive involved because that's what can really change.

For example, for my compute methods, I know I'll always be decorating methods with type Callable[[Any], ReactiveType].
So, what maybe I can have is an alias for compute methods and then use that.

The suggestion below seems to eliminate an error you get with make typecheck and it also gets rid of some IDE errors I get in several places.
However, I'm not 100% sure this is better.
It feels better, but I wouldn't bet my life on it.

# ...

ComputeMethodAlias: TypeAlias = Callable[[Any], ReactiveType]  # <--

# ...

class ComputeDecorator(Generic[ReactiveType]):  # <--
    def __init__(self, reactive: Reactive[ReactiveType] | None = None) -> None:  # <-- better typing here
        self._reactive = reactive

    @overload
    def __call__(self) -> ComputeDecorator[ReactiveType]: ...  # <--

    @overload
    def __call__(
        self, method: ComputeMethodAlias[ReactiveType]  # <--
    ) -> ComputeMethodAlias[ReactiveType]: ...  # <--

    def __call__(
        self, method: ComputeMethodAlias[ReactiveType] | None = None  # <--
    ) -> ComputeMethodAlias[ReactiveType] | ComputeDecorator[ReactiveType]:  # <--
        # ...

# ...

@rich.repr.auto
class Reactive(Generic[ReactiveType]):
    # ...
    def __init__(...):
        # ...
        self._compute_method: ComputeMethodAlias[ReactiveType] | None = None  # <--  better typing

    # ...

    @property
    def compute(self) -> ComputeDecorator[ReactiveType]:  # <--
        # ...

[rodrigogiraoserrao]

It was very difficult for me to spot the difference.
Would it be worth adding a comment # <-- to make the diff obvious so that no one deletes this test in the future by mistake?

[rodrigogiraoserrao]

Suggested change

	"""Test watchers defined via a decorator, that is called."""
	"""Test watchers defined via a decorator, that is called, when the reactive has init set."""

[darrenburns]

With this change, how would we override what a watcher does in a widget subclass?

If I have a count reactive declared in a widget which has a watcher defined, then I subclass that and I want my own watcher, how would I achieve this? In the child class, @count.watch doesn't work because count is not defined.

For example, this fails to run because NameError: name 'count' is not defined

    class Parent(Widget):
        count: Reactive[int] = reactive(0, init=False)

        @count.watch
        def _count_parent(self, new_value: int) -> None:
            print("parent watcher")

    class Child(Parent):

        @count.watch
        def _count_parent(self, new_value: int) -> None:
            print("child watcher")

@Parent.count.watch doesn't work because of the "only a single method may be decorated with watch".

Even if that's solved, there's still a bit of a developer experience issue that @davep mentioned, whereby we no longer know what the parent watch method is called without going looking for it.

[willmcgugan]

Going to park this for now. @darrenburns 's observation re inheritance may kill this idea entirely.

[darrenburns]

@willmcgugan Wondering if we should close this?

[willmcgugan]

Think I'll keep it around for a bit. Would like to give it another pass at some point.

[yggdr]

You can work around the NameError issue with the metaclass' __prepare__ method, e.g.

class M(type):
         @classmethod
         def __prepare__(cls, name, bases, **kwargs):
             for base in bases:
                 if base.__name__ == 'A':
                     return dict(a=base.a)
             return super().__prepare__(name, bases, **kwargs)

class A(metaclass=M):
    a=1

class B(A):
    print(a)

will print out 1.
When properly generalising this, I would create the MRO from the given list of bases, then go through them checking for attributes of type textual.reactive.reactive, and add the last one.