Closed kcpevey closed 6 years ago
And the other obvious thing: What if I wanted it to visualize as UTM Zone
?
That sounds like a mistake on our part. The label formatting is controlled by the label_formatter
argument to parambokeh.Widgets()
, which defaults to parambokeh.default_label_formatter
. default_label_formatter
has a capitalize
parameter, which is true by defauilt and calls Python's .capitalize()
method on the string. Python's capitalize
sounds like the right thing to do, but it actually lower cases all but the first character, which is not at all what was intended here. Seems like we need to fix that in parambokeh, i.e. to make it only capitalize the first letter and leave the rest unchanged:
if self.capitalize:
pname = pname[:1].upper() + pname[1:]
I haven't played with the param callable structure before which may be why I'm confused, but I'm struggling to understand how this works.
I tried to simply change one of the default formatting options:
parambokeh.Widgets(wmts_param, label_formatter=parambokeh.default_label_formatter(capitalize=False))
but that gives:
TypeError: __call__() got an unexpected keyword argument 'capitalize'
OR should I instead be trying to add some things to this overrides
parameter?
OR should I be writing my own callback altogether?
I was hoping it would be some standard string formatting, but it doesn't appear that's the case?
Also - I don't see an example of this in the docs, did I miss it?
default_label_formatter is a ParameterizedFunction, and those guys are (deliberately) a bit weird in that they are both classes (so that they can have Parameters) and also callable as functions. You can set this parameter at the class level:
from parambokeh import default_label_formatter
default_label_formatter.capitalize=False
Or you can create a new instance of the class with one of the parameters changed:
parambokeh.Widgets(wmts_param,label_formatter=parambokeh.default_label_formatter.instance(capitalize=False))
You can certainly write your own callback (any callable would do here, e.g. lambda x: x
), but that should only be needed for unusual requirements, and I don't think what you want to do is at all unusual. Here you could even do label_formatter=None
, to omit all formatting and just use the bare parameter names.
You can also add to overrides
, but again, I don't think you'd need that; that's intended for truly weird things on a case-by-case basis, and here you just want reliable, repeatable mapping from parameter names to widget names, which is the opposite of what overrides is intended for.
I'm not sure what you mean by standard string formatting; here the offending bit is just Python's standard .capitalize
method, which in my opinion shouldn't be affecting the case of the rest of the string by default, but that's just what the standard is...
We can leave this issue open as a reminder to document this aspect of parambokeh.
I have a parambokeh widget that is specified in my file as:
UTM_Zone = param.Integer(52, precedence=1.65)
In the parambokeh visualization, the name appears as
Utm zone
.I recognize this is part of being able to visualize a name different than the python coded assignment. While this does give me a little more readable name, its doing this automagically for me. Which means since I didn't actually tell it to use
Utm zone
, I'm over here wondering what regex happened to it. For example, sinceUtm zone
visualized, I immediately tried to access it viaUtm_zone
, then I triedutm_zone
, then finally I went back to the original code. I didn't like having to figure out what happened to it.Maybe this can be a discussion point of how the regex can be more apparent to the user or maybe param objects need to carry a
name
string which makes it obvious that you must access via the original code name?