I've been working with a the PyYAML
parser for a few months now to convert file types as part of a data pipeline. I've found the parser to be quite idiosyncratic at times and it seems that today I've stumbled on another strange behavior. The file I'm currently converting contains the following section:
off:
yes: "Flavor text for yes"
no: "Flavor text for no"
I keep a list of the current nesting in the dictionary so that I can construct a flat document, but save the nesting to convert back to YAML later on. I got a TypeError
saying I was trying to concatenate a str
and bool
type together. I investigated and found that PyYaml
is actually taking my section of text above and converting it to the following:
with open(filename, "r") as f:
data = yaml.load(f.read())
print data
>> {False: {True: "Flavor text for yes", False: "Flavor text for no}}
I did a quick check and found that PyYAML
was doing this for yes
, no
, true
, false
, on
, off
. It only does this conversion if the keys are unquoted. Quoted values and keys will be passed fine. Looking for solutions, I found this behavior documented here.
Although it might be helpful to others to know that quoting the keys will stop PyYAML
from doing this, I don't have this option as I am not the author of these files and have written my code to touch the data as little as possible.
Is there a workaround for this issue or a way to override the default conversion behavior in PyYAML
?
yaml.load
takes a second argument, a loader class (by default,yaml.loader.Loader
). The predefined loader is a mash up of a number of others:The
Constructor
class is the one performing the data type conversion. One (kludgy, but fast) way to override the boolean conversion could be:which overrides the function that the constructor uses to turn boolean-tagged data into Python booleans. What we're doing here is just returning the string, verbatim.
This affects ALL YAML loading, though, because you're overriding the behaviour of the default constructor. A more proper way to do things could be to create a new class derived from
Constructor
, and newLoader
object taking your custom constructor.PyYAML is YAML 1.1 conformant for parsing and emitting, and for YAML 1.1 this is at least partly documented behavior, so no idiosyncrasy at all, but conscious design.
In YAML 1.2 (which in 2009 superseded the 1.1 specification from 2005) this usage of
Off/On/Yes/No
was dropped, among other changes.In
ruamel.yaml
(disclaimer: I am the author of that package), theround_trip_loader
is a safe_loader that defaults to YAML 1.2 behaviour:Which gives:
If your output needs to be version 1.1 compatible then you can dump with an explicit
version=(1, 1)
.Since the quotes around the nested mapping's scalar values are unnecessary they are not emitted on writing out.
If you need to do this with PyYAML, rewrite the (global) rules it uses for boolean recognition:
Which gives:
This works because PyYAML keeps a global dict (
Resolver.yaml_implicit_resolvers
) which maps first letters to a list of (tag, re.match_pattern) values. For foro
,O
,y
andY
there is only one such pattern (and it can be deleted), but forn
/N
you can also matchnull
/Null
, so you have to delete the right pattern.After that removal
yes
,no
,on
,Off
are no longer recognised as bool, butTrue
andFalse
still are.Simply sanitize your input:
This is mucht better than blindly poking in the horrible depths of pyyaml. That packages comes with two, almost but not quite identical, sources and is a maintenance nightmare.