Behaviour of BindableProperty and lists

[BlankAdventure]

First Check

• I added a very descriptive title here.
• I have checked the FAQs for a similar question and didn't find it.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the NiceGUI documentation, with the integrated search.
• I already searched online "How to X in NiceGUI" and didn't find any information.

Example Code

import random
from nicegui.binding import BindableProperty, bind_from
from nicegui import ui

def x_func(x,y):
    print(f'x-func: {x} | {y}')
def y_func(x,y):
    print(f'y-func: {x} | {y}')

class App():
    # Define a descriptor with custom callback for each attribute we wish to monitor
    x_tracker=BindableProperty(on_change=lambda x,y : x_func(x,y))
    y_tracker=BindableProperty(on_change=lambda x,y : y_func(x,y))
    def __init__(self):
        self.x_tracker = None
        self.y_tracker = None 

app = App()

class Model():
    def __init__(self):
        self.x = 0
        self.y = []        
    def update(self, val):
        self.x = val
        self.y.append(val)        
        print(f'{app.x_tracker=} | {app.y_tracker=}' )

model = Model()

bind_from(self_obj=app, self_name='x_tracker',other_obj=model, other_name='x', backward=lambda t: t)
bind_from(self_obj=app, self_name='y_tracker',other_obj=model, other_name='y', backward=lambda t: t)


ui.button(icon='refresh', on_click=lambda: model.update(random.randint(0,30)))
ui.button(text='setattr', on_click=lambda: setattr(app, 'y_tracker', [-5]))

ui.run()

Description

I have a situation where I'm trying to detect changes to a list that exists in particular class from another library. See the attached code as a stripped down example.

In this code, I want to bind to changes in the attributes x and y of Model. The refresh button serves to simulate an external call that modifies these values. Model.x has been included simply as a baseline to show that everything is working as expected. The list attribute of Model.y is what we're interested in.

If you run the code and click the refresh button a few times, you'll see something like this:

app.x_tracker=15 | app.y_tracker=[24, 15, 24]
x-func: <__mp_main__.App object at 0x000001F21F936090> | 24

This shows that the binding is operating correctly -- the appended list values are getting propagated into App.y_tracker. However, notice that only the x_tracker callback (x_func) gets called, NOT the y_tracker callback. This is puzzling to me.

I know that only assignments trigger the __set__() method in a descriptor, not list mutations; but I think this is a red herring as the append operation only happens in Model, and the new value is in fact assigned to the attribute in App. This can be checked with the second button 'setattr', where I explicitly call setattr and see the following result:

y-func: <__mp_main__.App object at 0x000001F21F936090> | [-5]
y-func: <__mp_main__.App object at 0x000001F21F936090> | [24, 15, 24]

So, with setattr, the callback (y_func) is indeed called. An in fact, we see it gets 'reset' to its previous value right after, presumably as the loop cycles through and syncs with model.y. This in my mind confirms an assignment is taking place.

So, I'm confused with what exactly is happening in the binding module: an assignment certainly seems to be taking place, and therefore ought to trigger the __set__() method, and ultimately the callback.

NiceGUI Version

2.16.0

Python Version

3.11.11

Browser

Chrome

Operating System

Windows

Additional Context

No response

[BlankAdventure]

I did come up with the following work-around:

import random
from nicegui.binding import BindableProperty, bind_from
from nicegui import ui

class Customlist(list):
    def __init__(self, iterable):
        self.toggle = False
        super().__init__(iterable)
    def append(self,item):
        super().append(item)
        self.toggle = not self.toggle
        
class Model():
    def __init__(self):
        self.y = Customlist([])
    def update(self, val):
        self.y.append(val)
        print(f'{app.y_tracker=}' )

model = Model()

class App():
    y_tracker = BindableProperty(on_change=lambda sender,value : sender.changed(value))
    def __init__(self):
        self.y_tracker = None 
    def changed(self,value):
        print(f'{value=} | {model.y=}')

app = App()

bind_from(self_obj=app, self_name='y_tracker',other_obj=model.y, other_name='toggle', backward=lambda t: t)
ui.button(icon='refresh', on_click=lambda: model.update(random.randint(0,30)))
ui.run()

I moved things around a bit, but the main idea is that I created a custom list class that overrides append and set a toggle flag. Then, I bind to that attribute instead, in order to trigger the descriptor callback.

[falkoschindler]

Hi @BlankAdventure,

I think you're already on the right track: Is __set__ called or not?

1. I think we agree that this won't call __set__:

   self.y.append([1])

2. In contrast, this does call __set__ as expected:

   self.y = self.y + [1]

3. Both my linter linter and common sense suggest to simplify the previous expression like this:

   self.y += [1]

   But list seems to implement += differently and __set__ is not called.

In conclusion, we have to use the long form self.y = self.y + [1] to fix the original example:

class App:
    y = BindableProperty(lambda _, value: print('Y changed', value))

    def __init__(self):
        self.y = []

app = App()

class Model:
    def __init__(self):
        self.y = []

    def update(self):
        self.y = self.y + [1]
        print(f'{app.y=}')

model = Model()
bind_from(app, 'y', model, 'y')

ui.button('Update', on_click=model.update)

[BlankAdventure]

Ah, interestingly, I stumbled onto the same self.y = self.y + [1] solution as you posted.

However, I think I could still use some clarification as to how this binding stuff works exactly. My understanding is that there is a polling loop that detects changes in the source attribute (model.y) and propagates them to the target attribute (app.y or y_tracker in my original code). The source change detection does not seem to rely on __set__ (there is no descriptor in Model), and we can see indeed that calling append on model.y does get transmitted to app.y - I how this in my first code example. So to me it seems like the __set__ 'failure' is happening on the target end. Do you agree?

[falkoschindler]

Have a look at https://nicegui.io/documentation/section_binding_properties#bindable_properties_for_maximum_performance. It explains the difference between bindable properties (which listen to __set__ calls and don't need a loop) and other bindings which are indeed polled regularly.

[BlankAdventure]

So, I understand the difference (I think) but I'm not sure how that addresses the behviour under discussion.

In this case, there are no descriptors, no __set__ calls, and the binding is from model.y to app.y. This would be an active link case, yes? (model.y gets polled in a loop, change is detected, then app.y is assigned the new value, presumably via setattr).

from nicegui.binding import bind_from
from nicegui import ui
    
    
class App:
    def __init__(self):
        self.y = []

app = App()

class Model:
    def __init__(self):
        self.y = []

    def update(self):
        self.y.append(1)
        print(f'{app.y=}')

model = Model()
bind_from(app, 'y', model, 'y', backward=lambda t: t)

ui.button('Update', on_click=model.update)
ui.run()

Now lets go ahead and add one extra line:

from nicegui.binding import BindableProperty, bind_from
from nicegui import ui
    
    
class App:
    y = BindableProperty(lambda _, value: print('Y changed', value))
    def __init__(self):
        self.y = []

app = App()

class Model:
    def __init__(self):
        self.y = []

    def update(self):
        self.y.append(1)
        print(f'{app.y=}')

model = Model()
bind_from(app, 'y', model, 'y', backward=lambda t: t)

ui.button('Update', on_click=model.update)
ui.run()

That one extra line -- the addition of descriptor -- shouldn't change much. The polling loop is still running, observing the change in model.y and updating app.y with the new value. The weird bit to me then is why this doesn't now trigger the (new) __set__ method of app.y, given that presumably the update happens via a setattr assignment.

[falkoschindler]

why this doesn't now trigger the (new) __set__ method of app.y

Why do you think __set__ isn't called for app.y?