Lambdas in tranform field?

Hello,
I have uses a CustomJSTransform successfully to produce on-the-fly the values for the “size” of a scatter plot. Basically I am doing for size the same as what is done for y with the normalize used in this example.

However it seems a bit of an overkill to call in JS to just rescale some numbers. So I tried something like this with a lambda function.

p.scatter('x','y',
          , size={"field":'rad', "transform": lambda  x: x/10 }\
          , source=visite\
          , fill_alpha=0.15\
          ,fill_color={"field" :'fill_value',  "transform" : color_mapper}\
         , line_color='red')

Of course I got a Value Error because that lambda is not supported.

ValueError: expected an element of either String, Dict(Enum('expr', 'field', 'value', 'transform', 'units'), Either(String, Instance(Transform), Instance(Expression), Float)) or Float, got {'field': 'rad', 'transform': <function <lambda> at 0x7fd335d93b80>}

Am I just missing the syntax to use a lambda in the “transform” field or maybe I am the only one to feel the need for that?

Hi @foice, one of the confusing aspects of Bokeh for many users is that, although they use it by writing Python code, almost all the actual is done JavaScript code, in a browser. Transforms cannot be Python lambdas, because transform expression are only executed in a browser, i.e. they can only be JavaScript code.

There are a number of pre-made transforms that Bokeh provides, but if you need something custom, you can also use the CustomJSTransform to supply a snippet of JavaScript code to execute for the transform. There is an example in that link that is actually very similar to what you are trying to do above, so I won’t repeat it here.

Thanks for the explanation on the actual JS backend.

I think you are referring to the normalize JS example in the link, which is what I had done already. Or are you pointing me to another example more fit for my request?

No, the same one. There are very many support questions and only one of me, so I tend to read them very quickly and go straight to the code if there is code. I missed your first paragraph.

I guess I will add: we used to support something like this with a Python to JS transpiler but we deliberately removed it. It couldn’t work in all situations, blurred the runtime boundary in a way that confused people to think real Python code would be getting run, often required “weird” or unintuitive “Python” code as input, and in general was just a big source of support questions.

What you say makes a lot of sense.