pyyaml
strictyaml
Our great sponsors
pyyaml | strictyaml | |
---|---|---|
16 | 21 | |
2,425 | 1,407 | |
1.3% | - | |
3.9 | 1.9 | |
13 days ago | about 1 month ago | |
Python | Python | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
pyyaml
-
Cython 3.0 Released
PyYAML knew about the breakage since january 2022[0], and nothing really happened. After a year and a half with lots of alphas and betas, I don't think there is much cython could do, short of fixing PyYAML themselves.
[0]: https://github.com/yaml/pyyaml/issues/601
- Cython v3 release breaking PyYAML install well used in Python ecosystem
- Cython and pyyaml is breaking many builds
- I'm needing a hand, I do not understand some (seemingly) simple Python stuff.
-
is there any difference between using string.format() or an fstring?
They did finally change the default, in PyYAML 6, after many many bugs pointing out that their previous approach is broken (including one by yours truly), so the default is now safe.
-
Using Rust to not have to touch Yaml in k8s land
Note some parsers, most notably pyyaml are still at yaml 1.1, because 13 years is just not enough time to update it.
-
JSON is not a YAML subset
That part of the YAML 1.2 spec is in conflict with reality, though. The base of YAML 1.1 documents is large enough that a backwards-incompatible change to default behavior is for practical purposes impossible.
YAML 1.1 was released in 2005, and 1.2 in 2009 -- only four years later. But here we are, in 2022, and YAML 1.1 is still the default (in many cases, only) version supported. That's why the "Norway problem" persists -- it's not possible for the parser to know whether an un-versioned YAML document containing "a: no" should parse the same as {"a": false} or {"a": "no"}.
Python (PyYAML) doesn't support 1.2 yet: https://github.com/yaml/pyyaml/issues/116
Ruby (Psych) ditto -- I can't even find a tracking issue to enable it.
Go (go-yaml) is a mixture of YAML 1.1 and 1.2, depending on the author's preferences.
Also, as a rough guideline, you can't have a backwards-incompatible revision of a versioned spec declare that it's the new default version, because that breaks all existing users.
-
I accidentally used YAML.parse instead of JSON.parse, and it worked?
Many parsers either default to YAML pre-1.2 or do not even expose a YAML 1.2 option. PyYAML has no 1.2 option, for example. So unless Ansible is using something other than PyYAML...
Relevant (open) PR: https://github.com/yaml/pyyaml/pull/555
- AttributeError: '_io.TextIOWrapper' object has no attribute 'items'
-
Why doesn't yaml allow safe_dump for decimals?
Are you perhaps talking about decimal.Decimal? https://github.com/yaml/pyyaml/issues/255
strictyaml
- StrictYAML
-
XML is better than YAML
NestedText already is the way I use YAML; everything is intepreted as a string. I have some trust in my YAML parser to not mangle most strings. I could use NestedText, but users would be unfamiliar with it, and IIRC the only parsers are in Python. But then I could use StrictYaml too https://github.com/crdoconnor/strictyaml
-
The new type of SQL injection
you can stick to a subset of YAML syntax (e.g. strictYAML)
-
DO YOU YAML?
YAML stands for "YAML Ain’t Markup Language" - this is known as a recursive acronym. YAML is often used for writing configuration files. It’s human readable, easy to understand and can be used with other programming languages. Although YAML is commonly used in many disciplines, it has received criticism on the amoutn of whitespace .yml files have, difficulty in editing, and complexity of the standard. Despite the criticism, properly using YAML ensures that you can reproduce the results of a project and makes sure that the virtual environment packages play nicely with system packages. (If you're looking for another way to share environments there are other alternatives to YAML which include StrictYAML (a type-safe YAML parser) and NestedText)
-
The yaml document from hell
The example you linked provides this as an example of a YAML document that he wants his format to support.
-
The YAML Document from Hell
That safe subset exists and is implemented in a number of languages. It is called strict-yaml: https://hitchdev.com/strictyaml/
-
Hacker News top posts: Jul 3, 2022
StrictYAML\ (33 comments)
-
Why JSON Isn’t a Good Configuration Language (2018)
To me those are in the category of "nice to have", and the problem is that every developer has different preferences for these [1] [2]. But the main features of StrictYaml, like supporting comments and less syntactic noise, I think are pretty uncontroversial, and perhaps it's worth it to get people to switch over for those alone. It doesn't need to be perfect, it just needs to be a significant enough improvement over JSON, and I'd say those two features are more than enough
[1]: https://github.com/crdoconnor/strictyaml/issues/37
[2]: https://github.com/crdoconnor/strictyaml/issues/38
What are some alternatives?
confuse - painless YAML config files for Python
nestedtext - Human readable and writable data interchange format
yamllint - A linter for YAML files.
ytt - YAML templating tool that works on YAML structure instead of text
jsonnet - Jsonnet - The data templating language
crudini - A utility for manipulating ini files
marshmallow - A lightweight library for converting complex objects to and from simple Python datatypes.
yaml-rust - A pure rust YAML implementation.
python-strict-yaml-parsing - Examples of strict yaml parsing in python
starlark-go - Starlark in Go: the Starlark configuration language, implemented in Go
python-frontmatter - Parse and manage posts with YAML (or other) frontmatter
json5 - JSON5 — JSON for Humans