Handling new mandatory callback signatures with classes

Community Support
1

I have had a bokeh application running for the past 2 years (now using Bokeh version 0.12.15).

I tried using the latest version and it’s not backward compatible, at least in the way I programmed it. I have a tendency to always use classes as it is very practical to access any attribute, and because that’s how it is done with (py)qt.

However methods don’t fit the mandatory callback signature for Buttons & other widgets in later versions of Bokeh, and I receive the following error:

2019-07-25 08:22:10,709 Error running application handler <bokeh.application.handlers.directory.DirectoryHandler object at 0x0000023D12ADE9B0>: Event callback must have signature func(event), got func(*args, **kwargs)

It can be tested by cloning softfocus

My question is the following: is there a way to for me to slightly modify my Bokeh applications or do I have no other choice than using global variables and no class?

I couldn’t find any references or questions regarding this new callback signature. If this question was already answered and I missed it, please accept my apologies and redirect me to it.

last related question: is it possible to get professional support from Anaconda for Bokeh apps? I have sent an inquiry to Anaconda and got no response…

Thanks to Brian and the whole team!

2

My question is the following: is there a way to for me to slightly modify my Bokeh applications or do I have no other choice than using global variables and no class?

If understand your question, you want this to work:

class Foo(object):

    def callback(self, event):
        # use instance variables here

Are you saying that it does not work? It should work, otherwise it’s a bug.

Alternatively if the extra values you need are available when the callback is added, functools.partial is useful for that.

last related question: is it possible to get professional support from Anaconda for Bokeh apps? I have sent an inquiry to Anaconda and got no response

I am no longer with Anaconda (and the Bokeh project itself is now independently self-governing), but I can possibly put you in touch with someone there or point ot other alternatives if you send me a PM or mail at [email protected] to discuss.

3

Thanks Bryan, you made me realize I’m using a decorator function for all my callbacks. It is the culprit. Strangely the error message doesn’t report it, but if I comment it out I can run the server without problem.

I’ll need to see how I can modify it so that it doesn’t throw an error.

I’ll PM you once I’m back to work.

4

Oh, I see how that might trip things up. It’s possible we could consider loosening the callback checks. We might specifically allow *args, **kwargs functions, e.g. on the assumption that anyone using one knows what they are doing. Or perhaps there are other approaches to consider, like a flag to just disable the checks if that’s desired. I have found that in general, common case, it’s been helpful to get this feedback to users immediately right at the point of use, so I’d like to try and see what might be possible before considering removing them.

5

The decorator function is important for the “peace of mind” of my end users. Showing that it’s loading or explaining why something didn’t work is helpful, and I’d preferably not write it for each function.

After looking at your future._check_callback function, my decorator function now returns a function with explicit arguments: either [‘self’], [‘self’, ‘event’], or [‘self’, ‘attr’, ‘old’, ‘new’]. I believe I haven’t forgotten anything. It’s a bit hacky… but it works.

Thanks!

1 Like