Disable or take control over PyYAML's magic parsing of dates

[sigurdp]

PyYAML, has a lot of built-in "smart" (read magic) parsing of date and time values. When used with webviz-config this "smartness" can cause problems when the expected input to the target plugin is a string but the YAML file contains a value that PyYAML interprets as a date and returns as a Python datetime.date object.

For example the value 2010-10-09 will be interpreted as a date by PyYAML:

>>> import yaml
>>> yaml.safe_load("mykey: 2010-10-09")
{'mykey': datetime.date(2010, 10, 9)}

The work-around for such a case would be to enclose the value in quotes, forcing the value to be interpreted as a string. However, most of the time strings are specified without quotes in YAML files which can lead to confusing behavior and/or errors for unaware config file authors.

Currently there there are no webviz plugins that actually expect parameters of type datetime.date so we should probably disable this "smartness" in PyYAML. Unfortunately there seems to be no simple way of doing this, although some suggested "hacks" are described online. For example: https://stackoverflow.com/a/37958106/1122886

Alternatively we may want to use another library for YAML-parsing, for example ruamel.yaml, see this issue: #296

[asnyv]

Been thinking a bit about this. Do we really want webviz-config to not follow default yaml behavior, considering we don't have full control of all plugins?

Might be harder for people to use the configuration file if they cannot search up standard yaml syntax and get the behavior described there?

So my question is basically: Maybe we shall rather leave this responsibility to the plugin level?

[pinkwah]

Timestamps are a native YAML feature and not a "smartness" from PyYAML. Criticisms should be directed to the correct place. Also note that no is the same as false in YAML, ie:

enabled: no

"enabled": False
But this also leads to quirks such as:

country: NO

being interpreted as "country": False rather than "country": "NO".

I would strongly advise against messing with standard YAML behaviour lest we inadvertently invent EquinorYAML. We could adopt a different configuration ML instead.

[asnyv]

@sigurdp is it ok for you if we close this for now, and live with the "magic" behavior of yaml as is?

[sigurdp]

No worries. We'll just have to keep it in mind, and plugin users/implementors will at some point need to be aware of the behavior. As long as issues are discovered it is straightforward for the user to quote any problematic strings.

[asnyv]

Closing as it is default yaml behavior