Add support to load a yaml from a file about strictyaml HOT 8 CLOSED

What if I don't want to store a whole document in a string? What if I want to read a stream from the network? Why should I use an explicit str, not any other (lazy?) iterable? The stream api is quite common in Python, and ruamel.yaml provides support for it. It is expected that your load function also supports it.

I believe you should either focus on (1) bringing a replacement of ruamel.yaml API with type safety support (built on top of ruamel.yaml for instance), or (2) bringing a tool that allows to validate a json (before it is loaded in ruamel) or to validate the structure returned by ruamel.yaml.load.

This is an ugly line of code but it's necessary to be python 2/3 compatible.

I don't understand what is wrong about using isinstance in py2/3.

from strictyaml.

I don't like this behavior actually. There's a clear trade off to be made between explicitness/loose coupling and less code written. I don't think the trade off favors implicit behavior of reading a file.

1. Reading a file into a string is, in any case, a one or two liner so you're not typically saving a lot of characters.
2. Reading files has a wide variety of tricky edge cases encodings, file not found, filesystem errors, links, etc.) which I believe should be exposed to and handled by the programmer or a separate library instead of overloading the parser with that behavior.
3. Not all YAML will necessarily come directly from a file.

My code that does this typically works like so (using the lovely python library path.py)::

from path import Path
import strictyaml

config = strictyaml.load(Path("/path/to/file.yml").bytes().decode('utf8'))

I believe this balances explicitness, a balance of responsibilities between libraries and conciseness nicely.

I also strongly believe you should avoid using this kind of type comparisons and use isinstance instead.

This is an ugly line of code but it's necessary to be python 2/3 compatible.

Also consider adapting validators.py where types are checked using == which is clearly a bad idea

I'll look into this.

from strictyaml.

I'm sorry, in this case, I don't see any good reason to break the duck typing philosophy of Python.

This philosophy is in direct contradiction to line 2 of the zen of python: explicit is better than implicit.

I don't personally believe that either philosophy should be used dogmatically - there is a case by case trade off to be made between both. In this case I believe there's enough complication under the hood as it is to justify not putting even more implicit behavior in.

For objects that implement __ str __ and return YAML it isn't a problem just do strictyaml.load(str(object)). For file handles it's not a huge deal to just do .read().

I was expecting strictyaml to handle the same kind of cases than ruamel.yaml.

It's stricter.

from strictyaml.

What if I don't want to store a whole document in a string? What if I want to read a stream from the network?

I would probably use a new explicit API call for that e.g. load_stream. There's a large number of tricky issues with handling that use case which are absent from the use case of just loading a string.

I haven't considered that a priority since I'm focused on readability of the YAML used as a DSL or config file. Readable DSL/config file very much implies your file isn't a million lines long and fits in a string.

The stream api is quite common in Python

It is for other use cases but I don't see much of a need for loading short-ish config files or DSLs via the stream API. Where's the downside to loading streams into a string and parsing that?

I don't understand what is wrong about using isinstance in py2/3.

Try doing isinstance(u"x", unicode) in python 3.

from strictyaml.

I'm sorry, in this case, I don't see any good reason to break the duck typing philosophy of Python.

The strict type check is to make sure that you are sending a type that strictyaml will parse.

I was expecting strictyaml to handle the same kind of cases than ruamel.yaml.

from strictyaml.

I would probably use a new explicit API call for that e.g. load_stream. There's a large number of tricky issues with handling that use case which are absent from the use case of just loading a string.

I didn't look at the code, but why do you have to consider more tricky issues that the one that are currently handled by ruamel.yaml? Just pass the parameter to ruamel.yaml.load, and work with the returned value, no?

Try doing isinstance(u"x", unicode) in python 3.

Right! Exactly a good reason to remove this check :-D
(Or to use six, or to define unicode in Python 2 if needed, or...) ;)

from strictyaml.

I didn't look at the code, but why do you have to consider more tricky issues that the one that are currently handled by ruamel.yaml?

It has implications for validation as well. It might be possible to get it to work but it would require a pretty significant refactor.

Which, for a feature that as yet doesn't have a presented use case, I'm skeptical of the need for.

Right! Exactly a good reason to remove this check :-D (Or to use six, or to define unicode in Python 2 if needed, or...) ;)

The strict type check is to make sure that you are sending a type that strictyaml will parse. It won't parse integers, lists, file streams or anything else and so it should fail fast if you try.

I could introduce six but for a minor clean up one line of code I'd prefer to avoid the heaviness of the dependency.

from strictyaml.

That's unfortunate... :(

from strictyaml.