You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Custom values for griddash, e.g. '10px' don't work (plotly.js 2.12.0) #3710
ValueError:
Invalid value of type 'builtins.str' received for the 'griddash' property of layout.xaxis
Received value: '10px'
The 'griddash' property is a string and must be specified as:
- One of the following strings:
['solid', 'dot', 'dash', 'longdash', 'dashdot',
'longdashdot']
- A number that will be converted to a string
@archmoj, should it work like this? That throws an error fig.update_xaxes(showgrid=True, gridwidth=1, gridcolor='LightPink', griddash='10px')
The problem isn't the DashValidator actually, it's that for attributes like griddash, the validator being used is the StringValidator, because it looks like the codegen isn't able to figure out it needs to use the DashValidator. The DashValidatordoes admit numbers and the StringValidator does not.
The DashValidator does admit numbers and the StringValidator does not.
FWIW dash attributes are the only ones with valType: 'string' as well as enumerated values:
It's certainly nice the way DashValidator admits both our enumerated strings and the css length list pattern. But it's a pain to need to explicitly list where to use it. Can't we just delegate to it whenever valType: 'string' and a values list appear together?
I'll see what I can do. @jonmmease originally added this enumeration presumably because he felt another approach might be too brittle in a different direction. string and "has values" seems overly broad and likely to break later, no? Maybe string and "has dash and dotted in values" will be more robust?
Maybe string and "has dash and dotted in values" will be more robust?
I like that - hard to think what other case we'd want arbitrary strings plus enumerated values in the future, but if there is one it most likely wouldn't include dash and dot :)
Activity
nicolaskruchten commentedon May 5, 2022
It looks like our Python-side validation code for 'dash' strings is too restrictive.
archmoj commentedon May 9, 2022
I suspect this bug exists for every
line.dashattribute that has that have"valType": "string"andvaluese.g.archmoj commentedon May 9, 2022
Here is the current plotly.py validator:
plotly.py/packages/python/plotly/_plotly_utils/basevalidators.py
Lines 2245 to 2324 in d5b341c
nicolaskruchten commentedon May 9, 2022
Yeah I think that the schema is maybe not quite right in these cases?
Plotly.py is totally happy with the
line.dashattribute in scatter traces though:nicolaskruchten commentedon May 9, 2022
so what's different between
scatter.line.dashand the newgriddashin the schema?archmoj commentedon May 9, 2022
Could you simply set it to
10px?nicolaskruchten commentedon May 9, 2022
layout.shapes[].line.dashis also problematic.nicolaskruchten commentedon May 9, 2022
yes that works also
archmoj commentedon May 9, 2022
What happens if we do not validate by simply dropping
DashValidatorfunction?archmoj commentedon May 9, 2022
@alexcjohnson your thoughts?
nicolaskruchten commentedon May 9, 2022
Well, the whole purpose of
graph_objectsis to add validators, so just dropping them seems like the wrong way to go :)nicolaskruchten commentedon May 9, 2022
The problem isn't the
DashValidatoractually, it's that for attributes likegriddash, the validator being used is theStringValidator, because it looks like the codegen isn't able to figure out it needs to use theDashValidator. TheDashValidatordoes admit numbers and theStringValidatordoes not.Here is the code for the
scatter.line.dashvalidator and here is the code for thelayout.xaxis.gridddashvalidator.nicolaskruchten commentedon May 9, 2022
Oh, hah, here is why: https://github.com/plotly/plotly.py/blob/master/packages/python/plotly/codegen/utils.py#L184-L201
nicolaskruchten commentedon May 9, 2022
So where else do we need to use the
DashValidator? Looks likelayout.shapes[].line.dashand wherevergriddashended up. Anywhere else?archmoj commentedon May 9, 2022
Can't we instead say every attribute that ends with
dashshould be checked by the dash validator?nicolaskruchten commentedon May 9, 2022
It's a bit hard to crawl the whole thing like this I think, which is why we do this enumeration.
nicolaskruchten commentedon May 9, 2022
Let's fix this in the next patch release. I'm almost done QA'ing 5.8.0 already.
archmoj commentedon May 9, 2022
Good idea.
alexcjohnson commentedon May 9, 2022
FWIW
dashattributes are the only ones withvalType: 'string'as well as enumeratedvalues:It's certainly nice the way
DashValidatoradmits both our enumerated strings and the css length list pattern. But it's a pain to need to explicitly list where to use it. Can't we just delegate to it whenevervalType: 'string'and avalueslist appear together?nicolaskruchten commentedon May 9, 2022
I'll see what I can do. @jonmmease originally added this enumeration presumably because he felt another approach might be too brittle in a different direction. string and "has values" seems overly broad and likely to break later, no? Maybe string and "has
dashanddottedin values" will be more robust?alexcjohnson commentedon May 9, 2022
I like that - hard to think what other case we'd want arbitrary strings plus enumerated values in the future, but if there is one it most likely wouldn't include dash and dot :)
nicolaskruchten commentedon May 10, 2022
OK so I went with the "ends in
dashand is a string" approach instead as it was easier and didn't seem to get anything wrong.