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?
Python_versions:
- 3.8
- 3.9
Then we add the new version in our yaml file: Python_versions:
- 3.8
- 3.9
- 3.10
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.
Not reading the manual? Same thing would happen in JSON.
Sure it's annoying but all the YAML docs I've ever read state that unquoted numbers are ints/floats.
{"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?
In YAML you can just write blah and and it becomes a string. Except when it doesn't, when it matches some other type of value.
Which means anything that accepts YAML accepts JSON.
So you can write your Github action code in JSON (with a yml file extension).
That's false. http://p3rl.org/JSON::XS#JSON-and-YAML
It sounds like the differences are unlikely to be encountered in conventional config files, especially those written by hand.
From that link I understand the source of problems to be:
Object keys longer than 1024 "stream characters". But these wouldn't be valid in any other yaml syntax either.
Some Unicode characters in strings (characters outside of BMP).
An escape sequence that is technically valid in JSON but never required.