4 ms·

This is a reference to YAML parsing the two letter ISO country code for Norway: country: no As equivalent to a boolean falsy value: country: false I

This is a reference to YAML parsing the two letter ISO country code for Norway: country: no As equivalent to a boolean falsy value: country: false It is a relatively common source of problems. One solution is to escape the value: country: “no” More context: https://www.bram.us/2022/01/11/yaml-the-norway-problem/ https://www.bram.us/2022/01/11/yaml-the-norway-problem/

Y-bar 9mo ago
We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?
- actionfromafar 9mo ago
  Now add brackets and end-tags, I'll reconsider. ;)
  - Y-bar 9mo ago
    Brackets works fine: Roles: [editor, product_manager] End tags, that I’m not sure what that is. But three dashes is part of the spec to delineate sections: something: setting: true --- another: thing: false
- Etheryte 9mo ago
  Because there's a metric ton of software out there that was built once upon a time and then that bit was never updated. I've seen this issue out in the wild across more industries than I can count.
  - Y-bar 9mo ago
    I’m not here clanking down on Java for lacking Lambda features, the problem is that I did not update my Java environment past the 2014 version, not a problem with Java.
    - Etheryte 9mo ago
      I think this mixes up two separate things. If you're working with Java, it's conceivable that you could probably update with some effort. If you're an aerospace engineer using software that was certified decades ago for an exorbitant amount of money, it's never going to happen. Swap for nearly any industry of your liking, since most of the world runs on legacy software by definition. A very large number of people running into issues like these are not in a position where they could solve the problem even if they wanted to.
      - Y-bar 9mo ago
        That’s about 99% of the argument I am making. The problem is legacy software and bad certification workflows, not the software being used. If I’m working with Java it’s indeed conceivable that I could update with some effort. If I’m working with Node it’s conceivable that I could update with some effort. If I working with YAML is it not conceivable that I could update with some effort? PHP is stupid because version 3 did not support object oriented programming. CSS is bad because version 2 did not support grid layouts or flexbox. Why should I critique on these based on something that they have fixed a long time ago instead of working on updating to the version which contain the fix I am complaining about? There is a gradient limit where the onus shifts squarely to one side once the spec has changed and a number of libraries have begun supporting the new spec.
- quotemstr 9mo ago
  Because once a technology develops a reputation for having a problem it's practically impossible to rehabilitate it.
- merelysounds 9mo ago
  A new spec version doesn’t mean we stop having the problem. E.g. kubernetes wrote about solving this only five months ago[1] and by moving from yaml to kyaml, a yaml subset. [1]: https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak-peek/ https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak...
  - Y-bar 9mo ago
    The 1.1 spec was released about _twenty_ years ago, I explicitly used the word _implemented_ for a reason. As in: Our Yaml lib vendor had begun officially supporting that version more than ten years ago.
    - merelysounds 9mo ago
      Note that you reference 1.1, I think that version still had the norway behavior.
      - Y-bar 9mo ago
        1.1 partially fixed it, so that strings (quoted ”no”) did not become Boolean false. 1.2 strengthened it to remove unquoted no from list of tokens which could be interpreted as Boolean false.
        merelysounds 9mo ago
        > 1.1 partially fixed it, so that strings (quoted ”no”) did not become Boolean false. Do you have a source? Afaik v1.1 didn’t introduce such a change, v1.0 specified the same behavior for quoted strings, i.e. in v1.0 a quoted “no” would remain a string “no” as well.
- minitech 9mo ago
  Current PyYAML: >>> import yaml >>> yaml.safe_load("country: NO") {'country': False} Other people did not stop having this problem. It might be that there’s some setting that fixes this or some better library that everyone should be switching to, but YAML has nothing that I want and has been a repeated source of footguns, so I haven’t found it worth looking into. (I am vaguely aware that different tools do configure YAML parsing with different defaults, which is actually worse. It’s another layer of complexity on an already unnecessarily complex base language.)
  - Y-bar 9mo ago
    The ancient rule of ”use software that is updated with bugfixes” certainly applies here.
zzo38computer 9mo ago
I think it would be better to require quotation marks around all string values, in order to avoid this kind of problems. (It is not the only problem with YAML, but it is my opinion of how any format with multiple types should require explicitly mentioning if it is a string type, but YAML (and some other formats) doesn't.) (If keys are required to strings, then it can be reasonable to allow keys to be unquoted if the set of characters that unquoted keys can contain is restricted (and disallowing unquoted empty strings as keys).)

Y-bar 9mo ago

We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?

actionfromafar 9mo ago
Now add brackets and end-tags, I'll reconsider. ;)
- Y-bar 9mo ago
  Brackets works fine: Roles: [editor, product_manager] End tags, that I’m not sure what that is. But three dashes is part of the spec to delineate sections: something: setting: true --- another: thing: false
Etheryte 9mo ago
Because there's a metric ton of software out there that was built once upon a time and then that bit was never updated. I've seen this issue out in the wild across more industries than I can count.
- Y-bar 9mo ago
  I’m not here clanking down on Java for lacking Lambda features, the problem is that I did not update my Java environment past the 2014 version, not a problem with Java.
  - Etheryte 9mo ago
    I think this mixes up two separate things. If you're working with Java, it's conceivable that you could probably update with some effort. If you're an aerospace engineer using software that was certified decades ago for an exorbitant amount of money, it's never going to happen. Swap for nearly any industry of your liking, since most of the world runs on legacy software by definition. A very large number of people running into issues like these are not in a position where they could solve the problem even if they wanted to.
    - Y-bar 9mo ago
      That’s about 99% of the argument I am making. The problem is legacy software and bad certification workflows, not the software being used. If I’m working with Java it’s indeed conceivable that I could update with some effort. If I’m working with Node it’s conceivable that I could update with some effort. If I working with YAML is it not conceivable that I could update with some effort? PHP is stupid because version 3 did not support object oriented programming. CSS is bad because version 2 did not support grid layouts or flexbox. Why should I critique on these based on something that they have fixed a long time ago instead of working on updating to the version which contain the fix I am complaining about? There is a gradient limit where the onus shifts squarely to one side once the spec has changed and a number of libraries have begun supporting the new spec.
quotemstr 9mo ago
Because once a technology develops a reputation for having a problem it's practically impossible to rehabilitate it.
merelysounds 9mo ago
A new spec version doesn’t mean we stop having the problem. E.g. kubernetes wrote about solving this only five months ago[1] and by moving from yaml to kyaml, a yaml subset. [1]: https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak-peek/ https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak...
- Y-bar 9mo ago
  The 1.1 spec was released about _twenty_ years ago, I explicitly used the word _implemented_ for a reason. As in: Our Yaml lib vendor had begun officially supporting that version more than ten years ago.
  - merelysounds 9mo ago
    Note that you reference 1.1, I think that version still had the norway behavior.
    - Y-bar 9mo ago
      1.1 partially fixed it, so that strings (quoted ”no”) did not become Boolean false. 1.2 strengthened it to remove unquoted no from list of tokens which could be interpreted as Boolean false.
      - merelysounds 9mo ago
        > 1.1 partially fixed it, so that strings (quoted ”no”) did not become Boolean false. Do you have a source? Afaik v1.1 didn’t introduce such a change, v1.0 specified the same behavior for quoted strings, i.e. in v1.0 a quoted “no” would remain a string “no” as well.
minitech 9mo ago
Current PyYAML: >>> import yaml >>> yaml.safe_load("country: NO") {'country': False} Other people did not stop having this problem. It might be that there’s some setting that fixes this or some better library that everyone should be switching to, but YAML has nothing that I want and has been a repeated source of footguns, so I haven’t found it worth looking into. (I am vaguely aware that different tools do configure YAML parsing with different defaults, which is actually worse. It’s another layer of complexity on an already unnecessarily complex base language.)
- Y-bar 9mo ago
  The ancient rule of ”use software that is updated with bugfixes” certainly applies here.

zzo38computer 9mo ago

I think it would be better to require quotation marks around all string values, in order to avoid this kind of problems. (It is not the only problem with YAML, but it is my opinion of how any format with multiple types should require explicitly mentioning if it is a string type, but YAML (and some other formats) doesn't.) (If keys are required to strings, then it can be reasonable to allow keys to be unquoted if the set of characters that unquoted keys can contain is restricted (and disallowing unquoted empty strings as keys).)