GitLab

The PyYAML module recommends the use of safe_load if not parsing any
constructor tags. We don't support them, so our load function is actually
the same as the safe_load function. Consequently, we may as well define
the safe_load function to be the same thing, for compatibility with
anyone who might try to replace PyYAML with this module.

We may as well record the version we have decoded, as this means that
we may - in the future - support varying the behaviour of the parser
based on the YAML version.

The load() function is a little long and lint complains about the
number of blocks. I don't see an obvious way to fix that at this
moment, so I'm just annotating it to quiet the warning.

The key_value_re was overlong, so the string has been split into
multiple lines to make it tidier.

Rather than parsing the directives inline, they are now parsed as a
separate function. This reduces the complexity of the load function
a little.

In order that we can simplify the operations of the parser, I've
created a parser state which encapsulates the current state of
the parsing of the document. This will allow some of the parsing
operations to move into functions. It should also allow better
handling of some state-like processing, like knowing about
the YAML version, or references, if they were to be implemented
in the future.

The constructor handling for the YAML reading doesn't work with the
regular YAML parser, so I've moved it out of the way for now.

It's no longer used by pylint and generates warnings.

The examples have been taken from descriptions of the YAML formats
taken by a few programs. These are not especially complex, although
the appveyor example has been modified to make the `on` key into a
string, so that it is not parsed as a boolean.

PyYAML has been upgraded to 5.1, which may help some of the cases
we will introduce.

Documentation updated to note the behaviour of the parser with respect
to YAML versions.

When the PyYAML parser reports there are no documents at all (it
reports StopIteration immediately), we now fall back to trying to load
just the one document. I'm not sure if that's a PyYAML bug, but it's
relatively easy to work around.

Keys with dots in were not being processed, and were actually completely
ignored - the parser would not report an error. Errors due to unparseable
lines are now reported as such, rather than being silently dropped.

When the changes went in for floating point fixes, the dots were
incorrectly inserted into the 'not allowed' characters in the bare
key strings. These are now processed properly, and a test has been
added for that.

Exceptions were just being thrown out of the parser, which made it a
little harder to process. These are now captured into a YAMLError
exception, which will report the line the error occurred at.

Keys were being processed verbatim, so any quoting was ignored in the
key names. This has been improved, and the strings are now interpreted
as such. However, escapes aren't processed within those strings - they
might be handled in the future, but right now they're just passed
through.

I'm going to add some YAML files from public sources, so to do so,
I'm going to need a bit of space in the numbering sequence for the
tests. Easiest thing to do - increase to 3 digits.

A bare '.' matched the floating point number regex, which isn't right,
so I've added tests, and updated the code to ensure that it doesn't
match.

A few special cases have been added to try to ensure that we can
keep from regressing with some special text that is valid but hasn't
been tested till now.

The implicit key specification is a hard part to read within the
specification, but I think I've captured most of the 1.1 behaviour,
with sensible parsing for 1.2. My reading of the specification is
that the implicit keys should not have braces embedded in them,
but the YAML parser I use to validate against appears to allow
them (as does the http://www.yamllint.com/ validator). I'm unsure
why they're acceptable, so I've left them out right now.

New test 07_dict_keys.yaml includes checks for the keys being read
properly. This appears to be working, albeit with the numeric key
being left off the list - although it's processed, we generate the
key as a string, not as a number (which is what the comparison
parser does). Consequently, I'm leaving it out of the tests (it might
be sensible to introduce a special case in the test code to make
it acceptable to have differences of the number).

The values can be followed by comments. This was not supported, and as
it's a very common thing to want, I've added support for this.

Incorrect inheritance of Exception, redudant pass, method that can be static,
and an overly complex routine.

Since directives are allowed, and the %YAML directive is often used
to declare the version of YAML complied to, we probably should recognise
them. Even if we just use them to generate warnings.

The '-' at the start of the bare value isn't a list marker, but a
part of the string. This wasn't obvious from the examples I'd used,
but is made clear in the spec.

The module's purpose is really only for restricted cases where we
need to have a parser that doesn't include anything but the standard
library. Making this clear, together with its restrictions may help
anyone coming to look at this later.

It's also a simple replacement for a YAML parser, should that be
necessary - and vice-versa.

Pylint 1.9.4 is the last Python 2 pylint; we can use that or the 2.2.2
which is the current latest pylint present.

Upgrading pylint reports different errors, so these have been fixed.

String escapes are now expanded to include all of the escapes documented
in 1.1. This is probably escessive, but it means that we should at least
be able to support some of the more special cases we might use it for.

Improves coverage.

To check for support for unichr, there is an exception handler, which
is broad, but oh well.

'unichr' was needed to create characters for the \u escape, but this
is just 'chr' in python 2.

CI testing added, and configured so that we should have some tests
for the code executed when we push to gitlab.

The test code is now separate from the main class implementation
which should make it easier to run as an automation.

Making the SimpleYAML class more self-contained, this should be one
of the final steps to ensuring that the class can be dropped in
anywhere.

With the entire implementation in a class, it should be a lot easier
to lift into other code in the future. The whole point of this
implementation is that we don't need to provide a full YAML module
to be installed into the environment. This may simplify things.

The support that's present is only in the rudimentary key values
which follow an empty key. The '>' and '|' multi-line values are
not supported.

This is a basic implementation that provides the ability to parse
basic YAML files (not the full implementation - it's quite a bit
simpler).