I parse the following YAML data in python:
>>> import yaml
>>> yaml.load("""
... ---
... categories: {1: Yes, 2: No}
... increasing: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10]
... ...
... """)
And get this as output:
{'increasing': [0, 1, 2, 3, 4, 5, 6, 7, '08', '09', 10], 'categories': {1: True, 2: False}}
- Why are "Yes" and "No" converted to True and False?
- Why are "08" and "09" parsed as strings whereas the other digits are parsed as numbers with leading zeros truncated?
Yes
andNo
have special meanings in YAML. Have a look at the Wikipedia article. To circumvent this you could change your YAML to include quotes and look like thisRegarding the leading zeroes of 08 and 09 i am not quite sure why this is happening, but it does'nt seem to be a python issue
Your deduction that for
00
to07
the leading zeros are truncated is incorrect. These are all octal characters because of the leading0
and interpreted as such.As octal characters cannot contain
8
or9
the08
and09
cannot be anything but strings, and your YAML parser loads them as such.This is actually a leftover (backwards compatibility) with YAML 1.1 in YAML 1.2 octal numbers should start with
0o
That
Yes
andNo
are loaded asTrue
andFalse
resp. is also a YAML-1.1-ishm. The 1.2 specification no longer refers to these alternatives. If you quote those strings, they will not be convertedYou can relatively easily build a resolver that doesn't accept the Yes/No/On/Off variants for True/False by adding the following rule:
or by using the normal
Resolver
and deleting the appropriate start symbol entries:gives you:
Making all number-only strings that start with 0 to be recognised as normal integers is not so simple, because if you change the implicit resolver for
int
and pass the strings on that start with 0, you get a parsing problem, because08
is converted based on octal ¹:and that prints:
(it also does Yes/No as strings, without first inserting the recognition patterns in the internal lookup table)
¹ I used ruamel.yaml for this, of which I am the author. PyYAML, on which ruamel.yaml is based, should be able to support a similar derivation.