Discussion : Choisir un format de configuration : JSON, YAML ou TOML

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Traduction indisponible ; l’original est affiché. Original

Versions- und Bibliotheksdetails, an denen die Empfehlungen hängen. Python liest TOML seit 3.11 mit `tomllib` aus der Standardbibliothek, aber nur lesend; Schreiben braucht `tomli-w` oder `tomlkit`. PyYAMLs `yaml.safe_load` folgt weiterhin dem 1.1-Modell (`no` wird zu `False`, `1e3` bleibt eine Zeichenkette); ein Lader nach dem 1.2-Kern-Schema ist in Python `ruamel.yaml`. In Go beschreibt die README von `yaml.v3`, dass `yes`/`no`/`on`/`off` nur dann als Wahrheitswerte gelten, wenn in ein typisiertes `bool`-Feld dekodiert wird, sonst als Zeichenketten – das Verhalten hängt also auch vom Zieltyp ab, nicht nur vom Lader. Zu doppelten JSON-Schlüsseln: RFC 7493 (I-JSON) verschärft das SHOULD aus RFC 8259 zu einem MUST NOT, und Pythons `json.loads` behält still das letzte Paar; wer Duplikate ablehnen will, prüft sie über `object_pairs_hook`. Für die Schemaprüfung von YAML-Dateien haben sich Editoren auf den Kommentar `# yaml-language-server: $schema=<url>` geeinigt, und die Sammlung unter schemastore.org liefert Schemata für die meisten Werkzeugkonfigurationen (CI-Dateien, `pyproject.toml`, Compose).

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Traduction indisponible ; l’original est affiché. Original

«Einen Lader nach dem 1.2-Kern-Schema wählen» hilft genau dort nicht, wo der Artikel YAML empfiehlt: In CI-Pipelines, Kubernetes und Compose wählt der Konsument den Lader, nicht die Autorin. Kubernetes' `sigs.k8s.io/yaml` baut auf einem go-yaml-v2-Fork mit 1.1-Regeln auf, und GitHub Actions ist das bekannteste Zeichen dafür, dass das Ökosystem in 1.1 lebt: Der Schlüssel `on:` wird von PyYAML zu `True`. Jede Datei, die eine Autorin mit einem 1.2-Lader prüft, kann beim Empfänger anders gelesen werden, und sie merkt es erst am Verhalten. Die brauchbare Regel ist deshalb nicht «den richtigen Lader wählen», sondern «für den strengsten Lader schreiben»: alles zitieren, was in irgendeiner YAML-Fassung ein Skalar anderen Typs sein könnte (`yes`, `no`, `on`, `off`, `NO`, `1e3`, `1.10`, `0777`, `12:30`), und das mit einem Linter erzwingen – yamllints Regel `truthy` meldet unzitierte `yes`/`no`/`on`/`off` bereits in der Vorgabe, und eine Schemaprüfung fängt den Rest. Der Absatz sollte den Lader-Rat auf Dateien beschränken, die das eigene Programm liest, und für fremde Ökosysteme die Zitier- und Linter-Regel an seine Stelle setzen.