4 ms·

The YAML spec requiring turning "yes" "1" to true, and "no" "0" to false is one of the most aggravating things about YAML.

wtetzner 8y ago
Yeah, they probably should have had special syntax for booleans.
- majewsky 8y ago
  The problem is that they have too much special syntax for booleans.
  - wtetzner 8y ago
    I meant that they should have special syntax that isn't ambiguous (to a human reader). Just treating bare words as either strings or booleans depending on their value is what makes it confusing.
oftenwrong 8y ago
Also "on" and "off", and variations. "y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF" https://yaml.org/type/bool.html https://yaml.org/type/bool.html
- stevelosh 8y ago
  "NO" being false is particularly fun: - languages: - en # english - is # icelandic - no # norwegian - ja # japanese - fr # french [{"languages": ["en", "is", false, "ja", "fr"]}]
  - rmdashrfstar 8y ago
    That's so entirely ridiculous...
  - yellowapple 8y ago
    I feel like 99% of YAML's problems (this being the case in point) would be solved by just treating everything as a string and letting the application interpret it whichever way it sees fit.
    - slavik81 8y ago
      That's basically the idea behind StrictYaml. Unless you provide a schema, all fields are parsed as string, list or OrderedDict.
crdoconnor 8y ago
I created a library that just ignores that part of the spec and parses everything that isn't defined in a schema as a string: http://github.com/crdoconnor/strictyaml http://github.com/crdoconnor/strictyaml It also does away with a few other anti-features (e.g. the object parsing that led to the epic RoR security hole) and there's a long justification for each. I would like somehow to create a new spec out of this and see it implemented in programming languages other than python.

4 ms·

The YAML spec requiring turning "yes" "1" to true, and "no" "0" to false is one of the most aggravating things about YAML.

by jtreminio 8y ago

wtetzner 8y ago
Yeah, they probably should have had special syntax for booleans.
- majewsky 8y ago
  The problem is that they have too much special syntax for booleans.
  - wtetzner 8y ago
    I meant that they should have special syntax that isn't ambiguous (to a human reader). Just treating bare words as either strings or booleans depending on their value is what makes it confusing.
oftenwrong 8y ago
Also "on" and "off", and variations. "y|Y|yes|Yes|YES|n|N|no|No|NO |true|True|TRUE|false|False|FALSE |on|On|ON|off|Off|OFF" https://yaml.org/type/bool.html https://yaml.org/type/bool.html
- stevelosh 8y ago
  "NO" being false is particularly fun: - languages: - en # english - is # icelandic - no # norwegian - ja # japanese - fr # french [{"languages": ["en", "is", false, "ja", "fr"]}]
  - rmdashrfstar 8y ago
    That's so entirely ridiculous...
  - yellowapple 8y ago
    I feel like 99% of YAML's problems (this being the case in point) would be solved by just treating everything as a string and letting the application interpret it whichever way it sees fit.
    - slavik81 8y ago
      That's basically the idea behind StrictYaml. Unless you provide a schema, all fields are parsed as string, list or OrderedDict.
crdoconnor 8y ago
I created a library that just ignores that part of the spec and parses everything that isn't defined in a schema as a string: http://github.com/crdoconnor/strictyaml http://github.com/crdoconnor/strictyaml It also does away with a few other anti-features (e.g. the object parsing that led to the epic RoR security hole) and there's a long justification for each. I would like somehow to create a new spec out of this and see it implemented in programming languages other than python.