Simpler option setting
See original GitHub issueIs there a fundamental reason why we can’t do:
hv.Points(data)(color='red'})
instead of:
hv.Points(data)(style={'color':"red"})
I.e., does the distinction between the different types of options need to be something the user worries about in practice? Couldn’t holoviews just take a single list of keyword options and apply it to the plot options, style options, and normalization options in order, giving an error if none of those three were to consume it? It’s unlikely that any of the normalization options will ever match the name of one of the other two types, but of course it’s possible that there is a style option that has the same name as one of the plot options. Even so, (a) if that happens it’s going to be very confusing for our users no matter what we do, so it’s presumably good to avoid such name clashes, and (b) as long as we clearly define which option type has priority, people can deal with this issue for the very rare cases when it comes up, without having to use such a wordy and awkward syntax the rest of the time. What do you think?
Issue Analytics
- State:
- Created 8 years ago
- Comments:21 (21 by maintainers)
Top GitHub Comments
Sure, it’s a very important distinction for us as developers to make and for us to make clear in our docs; users do need to be able to find out which kind it is. But they really don’t need to remember which kind it is to use it. E.g. “height” – why should they care whether it’s a plot or style option? People can use it just fine without consulting any documentation, and it’s just an irritation to have to try one way and then switch it to the other to make it work. There’s no deep reason it is a plot vs. a style option, at least not one evident to users, so why force everyone to remember arbitrary information like that, or to use trial and error to get it to work? It’s a very unfriendly policy; we as developers can keep the two types straight all we want without having to require each and every user to do it every time they use them. Why make users jump through pointless hoops, and make all our examples and applications needlessly more verbose?
Finally implemented.