[BUG] "line_color" not applied from YAML theme file

ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)

Python version      :  3.7.2 (default, Mar 15 2019, 01:06:31) 
IPython version     :  (not installed)
Tornado version     :  6.0.3
Bokeh version       :  1.3.0
BokehJS static path :  /usr/local/lib/python3.7/site-packages/bokeh/server/static
node.js version     :  v10.15.1
npm version         :  6.10.0

OS: Mac OS X Mojave 10.14.6 Browser: Google Chrome Version 76.0.3809.100 (Official Build) (64-bit)

Description of expected behavior and the observed behavior Expected behavior: theme should be applied so line_color should be set to red Observed behavior: line_color is not applied (remains default)

Complete, minimal, self-contained example code that reproduces the issue

main.py

from bokeh.plotting import curdoc, figure

plot = figure()
plot.line(x = [1, 2], y = [1, 2])

curdoc().add_root(plot) 

theme.yaml

attrs: 
    Line:
        line_width: 10
        line_color: "#FF0000"  

Additional info

Both files are in test_yaml directory. The app is run as follows: bokeh serve --show yaml_test

No JS console warnings or error are given.

The plot looks like:

[bryevdv]

@solstag that’s perfect text, I will add that to the docs in a PR soon (unless you or someone else gets to it sooner!)

[bryevdv]

I actually spoke too hastily. I thought the _pop_colors_and_alpha function was written to coincidentally return the same color as the Line.line_color property default value. But that’s not the case. It just returns the value of get_default_color which is whatever it is, and unrelated to the property default, More importantly means that the plotting API setting its own defaults requires actually setting new property values, and that means that any theme values for those properties are overridden. (Explicitly set values always override theme values which always override property base defaults, definitely do not want to make any exceptions to that precedence rule at all)

Thinking about more things, I am not sure there is a reasonable alternative here:

• Even if if we wanted to special-case a comparison directly with a Theme object (to avoid setting a value if there is themed one), there is nothing requiring a theme to be set yet at the point in time when p.line is called. Nothing prevents anyone from waiting until the very end of their code to supply a theme, at which point it is too late to make a comparison, because p.line was already called and done.

• setting a theme for line color actually seems odd. Themes were imagined for: make the background color on all these 5 plots the same, or set the same font on every axis. But lines? Most plots that have lines have more than one, in which case a theme makes no sense, because multiple lines in a plot are almost always different colors. And if you do just have one line on the plot, well, it’s actually less work to just set it in code.

The only meaningful case I can think of is: I have N plots all with just one line each, and I want them to all have the same color. And if theming is really desired in that case instead of setting programmatically, well there is way: call p.add_glyph(source, Line(...)) instead of the higher level p.line

I’m leaning towards closing this with noaction or possibly just a note stating that line color and alpha are not theme-able in conjunction with the bokeh.plotting API. This is just such a corner case it’s hard to justify the amount of hoops that would be required to jump through to change it.