The issue with YAML is that it does not unambiguously distinguish between number/booleans and strings. JSON does, but only for numbers, booleans, and nulls. But there are many data types that need to be conveyed. For example, dates and quantities (numbers with units, such as $3.14 or 47kΩ). Such things are left to the application to interpret. Even JSON does not unambiguously distinguish between integers and reals. Even so, JSON pays for its lack of ambiguity by requiring all strings to be quoted, which adds clutter and the requirement for quoting and escaping. Thus, supporting those extra types comes at a cost.
I think NestedText is unique in leaving all leaf values as strings, so it does not need quoting or escaping.
Everything involves a compromise. YAML provides a lack of clutter at the cost of ambiguity. JSON is unambiguous, but comes with visual clutter. In both cases there are still lots of types they cannot handle and so must be passed on to the application.
The compromise with NestedText is that it provides simplicity and a lack of clutter by not supporting any data types for leaf values other than string. Thus, all interpretation of the text is deferred to the application. But fundamentally that is the best place for it, because only the application understands the context and knows what is expected.
I think the important difference between NestedText and YAML is that NestedText does not try to convert the text to numbers or booleans. YAML converts on to True and 3.10 to 3.1, which in this case is undesired. NestedText keeps text as strings. The idea is that end application should be the one that determines if on is a string or a boolean and whether 3.10 is a string or a number.
Its all in the name. All leaf values are strings. It is literally nested text.
The person that creates the config file does not necessarily choose the config file format. In the example, github chose YAML and everyone using github actions must use it. YAML is error prone, as everyone that tests with Python is finding out as the add Python 3.10 to their regression tests. This is a plea to organizations like github to stop choosing YAML.
As not a Python programmer, I'm struggling to understand the issue.
Your (or blogger's) claim is that GitHub misparses the YAML actions config when it comes specifically to Python? Or that YAML is inherently inadequate to the task of representing Python's necessary actions?
But now we discover that 3.10 is parsed as a float, just like the other ones were. But the problem is that 3.10 becomes 3.1, the equivalent float value! With 3.9 we didn't notice this problem.
I'm not sure what the name for this problem is.
It's something like.. an unfaithful but unintentionally working representation. Until it doesn't work anymore. The solution in YAML is to quote the values so that they become strings as intended.
How is that different from other formats? Take JSON:
{"python_versions": [3.8, 3.9, 3.10]}
This is a problem in any config language that doesn't enforce types, and jf it does enforce types, you should've used quotes already (like you really should've been before 3.10 was added to the list).
Similar problems also exist in many config formats with scientific notation (2e345) or hexadecimal notation (0x12345) or octal notation (012345, no that's not a decimal number in many programming languages and config formats!).
What commonly supported alternative would you suggest for this use case?
