HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
crdoconnor
strictyaml
Python2016–2025
crdoconnor / strictyaml

strictyaml

Type-safe YAML parser and validator.

25Distinct people
41Mentions
1Explicit recommenders
1.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Type-safe YAML parser and validator.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I love the example at https://github.com/crdoconnor/strictyaml/blob/master/FAQ.rst.... Convinced in 2 seconds that full YAML is idiotic.

akkartik used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year41 dated mentions

Observed mentions: 2016-08-01 10:26:16 UTC to 2025-08-09 14:14:43 UTC.

02462016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC707
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC716
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC716
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC404
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
StrictYAML StrictYAML is a type-safe YAML parser that parses and validates a restricted subset of the YAML specification. Priorities: Beautiful API Refusing to parse the ugly, hard to read and insecure features of YAML like the Norway problem. Strict validation of markup and straightforward type casting. Clear, readable exceptions with code snippets and line numbers. Acting as a near-drop in replacement for pyyaml, ruamel.yaml or poyo. Ability to read in YAML, make changes and write it out again with comments preserved. Not speed, currently. Simple example: # All about the character name: Ford Prefect age: 42 possessions: - Towel from strictyaml import load, Map, Str, Int, Seq, YAMLError Default parse result: >>> load(yaml_snippet) YAML({'name': 'Ford Prefect', 'age': '42', 'possessions': ['Towel']}) All data is string, list or OrderedDict: >>> load(yaml_snippet).data {'name': 'Ford Prefect', 'age': '42', 'possessions': ['Towel']} Quickstart with schema: from strictyaml import load, Map, Str, Int, Seq, YAMLError schema = Map({"name": Str(), "age": Int(), "possessions": Seq(Str())}) 42 is now parsed as an integer: >>> person = load(yaml_snippet, schema) >>> person.data {'name': 'Ford Prefect', 'age': 42, 'possessions': ['Towel']} A YAMLError will be raised if there are syntactic problems, violations of your schema or use of disallowed YAML features: # All about the character name: Ford Prefect age: 42 For example, a schema violation: try: person = load(yaml_snippet, schema) except YAMLError as error: print(error) while parsing a mapping in "<unicode string>", line 1, column 1: # All about the character ^ (line: 1) required key(s) 'possessions' not found in "<unicode string>", line 3, column 1: age: '42' ^ (line: 3) If parsed correctly: from strictyaml import load, Map, Str, Int, Seq, YAMLError, as_document schema = Map({"name": Str(), "age": Int(), "possessions": Seq(Str())}) You can modify values and write out the YAML with comments preserved: person = load(yaml_snippet, schema) person['age'] = 43 print(person.as_yaml()) # All about the character name: Ford Prefect age: 43 possessions: - Towel As well as look up line numbers: >>> person = load(yaml_snippet, schema) >>> person['possessions'][0].start_line 5 And construct YAML documents from dicts or lists: print(as_document({"x": 1}).as_yaml()) x: 1 Install $ pip install strictyaml Why StrictYAML? There are a number of formats and approaches that can achieve more or less the same purpose as StrictYAML. I've tried to make it the best one. Below is a series of documented justifications: Why avoid using environment variables as configuration? Why not use HJSON? Why not HOCON? Why not use INI files? Why not use JSON Schema for validation? Why not JSON for simple configuration files? Why not JSON5? Why not use the YAML 1.2 standard? - we don't need a new standard! Why not use kwalify with standard YAML to validate my YAML? Why not use Python's schema library (or similar) for validation? Why not use SDLang? What is wrong with TOML? Why shouldn't I just use Python code for configuration? Why not use XML for configuration or DSLs? Using StrictYAML How to: Build a YAML document from scratch in code Either/or schema validation of different, equally valid different kinds of YAML Labeling exceptions Merge YAML documents Revalidate an already validated document Reading in YAML, editing it and writing it back out Get line numbers of YAML elements Parsing YAML without a schema Compound validators: Fixed length sequences (FixedSeq) Mappings combining defined and undefined keys (MapCombined) Mappings with arbitrary key names (MapPattern) Mapping with defined keys and a custom key validator (Map) Using a YAML object of a parsed mapping Mappings with defined keys (Map) Optional keys with defaults (Map/Optional) Validating optional keys in mappings (Map) Sequences of unique items (UniqueSeq) Sequence/list validator (Seq) Updating document with a schema Scalar validators: Boolean (Bool) Parsing comma separated items (CommaSeparated) Datetimes (Datetime) Decimal numbers (Decimal) Email and URL validators Empty key validation Enumerated scalars (Enum) Floating point numbers (Float) Hexadecimal Integers (HexInt) Integers (Int) Validating strings with regexes (Regex) Parsing strings (Str) Restrictions: Disallowed YAML Duplicate keys Dirty load Design justifications There are some design decisions in StrictYAML which are controversial and/or not obvious. Those are documented here: What is wrong with duplicate keys? What is wrong with explicit tags? What is wrong with flow-style YAML? The Norway Problem - why StrictYAML refuses to do implicit typing and so should you What is wrong with node anchors and references? Why does StrictYAML not parse direct representations of Python objects? Why does StrictYAML only parse from strings and not files? Why is parsing speed not a high priority for StrictYAML? What is syntax typing? Why does StrictYAML make you define a schema in Python - a Turing-complete language? Star Contributors @wwoods @chrisburr @jnichols0 Other Contributors @eulores @WaltWoods @ChristopherGS @gvx @AlexandreDecan @lots0logs @tobbez @jaredsampson @BoboTIG StrictYAML also includes code from ruamel.yaml, Copyright Anthon van der Neut. Contributing Before writing any code, please read the tutorial on contributing to hitchdev libraries. Before writing any code, if you're proposing a new feature, please raise it on github. If it's an existing feature / bug, please comment and briefly describe how you're going to implement it. All code needs to come accompanied with a story that exercises it or a modification to an existing story. This is used both to test the code and build the documentation.
Read the full README on GitHub

What Hacker News says

41 sources
I found that post unconvincing. > It's very verbose. This is his example: https://github.com/crdoconnor/strictyaml/blob/master/hitch/s... I think you shouldn't use yaml or toml for this. > TOML's hierarchies are difficult to infer from syntax alone True! The point of TOML is to flatten the hierarchical structures. I would argue your configuration files shouldn't have much nesting anyway. > Overcomplication: Like YAML, TOML has too many features Basically TOML has a date type and all associated problems and advantages. I think it's a reasonable thing to include. > Syntax typing I think this is a good thing. I want to know whether something is a string or a number.
In I prefer human-readable file formats
I dont think it is about discipline. Discipline is required if you're duplicating tedious work, not for creativity. At its core, a good test will take an example and do something with it to demonstrate an outcome. That's exactly what how to docs do - often with the exact same examples. Logically, they should be the same thing. You just need a (non turing complete) language that is dual use - it generates docs and runs tests. For example: https://github.com/crdoconnor/strictyaml/blob/master/hitch/s... And: https://hitchdev.com/strictyaml/using/alpha/scalar/email-and...
In Unit tests as documentation
That's not really a problem with YAML it's an abuse of YAML. Accidental turing completeness is a problem all over, too. I remember using Ant 15 years ago - built in XML. It was the same problem and that wasn't XML's I think a lack of type safety is the main problem with YAML - a wrong indentation, a typo in a key, a string that gets parsed as a boolean, etc. Other than that I think it's a great format - terse and far less syntactic noise than other formats. This is why I wrote https://github.com/crdoconnor/strictyaml so people could write type safe yaml and get instantaneous, clear error messages on those things.
In That's a Lot of YAML
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
In Why JSON Isn’t A Good Configuration Language (2018)
The world desperately needs a replacement for YAML. TOML is fine for configuration, but not an adequate solution for representing arbitrary data. JSON is a fine data exchange format, but is not particularly human-friendly, and is especially poor for editable content: Lacks comments, multi-line strings, is far too strict about unimportant syntax, etc. Jsonnet (a derivative of Google's internal configuration language) is very good, but has failed to reach widespread adoption. Cue is a newer Jsonnet-inspired language that ticks a lot of boxes for me (strict, schema support, human-readable, compact), but has not seen wide adoption. Protobuf has a JSON-like text format that's friendlier, but I don't think it's widely adopted, and as I recall, it inherits a lot of Protobufisms. Dhall is interesting, but a bit too complex to replace YAML. Starla
Read the rest
rk is a neat language, but has the same problem as Dhall. It's essentially a stripped-down Python. Amazon Ion [1] is neat, but I've not seen any adoption outside of AWS. NestedText [2] looks promising, but it's just a Python library. StrictYAML [3] is a nice attempt at cleaning up YAML. But we need a new language with wide adoption across many popular languages, and this is Python only. Any others? [1] https://amzn.github.io/ion-docs/ [2] https://nestedtext.org/ [3] https://github.com/crdoconnor/strictyaml/
In The Norway Problem

Showing the 15 most recent of 41 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.