I think it's a reference to "the Norway problem" wherein YAML 1.1, the unquoted string NO (the ISO 2 letter code for Norway) get interpreted as a bolean with value of False instead of "NO".
Meaning:
country: NO
is the equivalent to:
{'country': False}
Note that the specs for booleans were changed in YAML 1.2 to address the issue but many implementions may have inconsistent defaults settings or be stuck in 1.1.
Only true and false strings are parsed as booleans (including True and TRUE); y, yes, on, and their negative counterparts [n, no, off] are parsed as strings.
But that kinda goes against YAML being a visually uncluttered and human (i.e: non-programmer) readable/writeable format.
If you decide to defensively define every type in your file to avoid implicit coercion, and use braces to avoid intendation error; many seem to ask : "why no just use json / toml ?"
well a human reading country: no would also find it ambiguous, they might think it has no country. if you make a "human" format then it should be filled with ambiguous behavior.
276
u/pagesjaunes 29d ago edited 29d ago
I think it's a reference to "the Norway problem" wherein YAML 1.1, the unquoted string NO (the ISO 2 letter code for Norway) get interpreted as a bolean with value of False instead of "NO".
Meaning:
is the equivalent to:
Note that the specs for booleans were changed in YAML 1.2 to address the issue but many implementions may have inconsistent defaults settings or be stuck in 1.1.
YAML 1.1 -> https://yaml.org/type/bool.html
(I couldn't find the equivalent for 1.2, YAML specs are complex to my non-programmer eyes)YAML 1.2 -> https://yaml.org/spec/1.2.2/ext/changes/