format: a JSON document can be minified or indented - #84
Merged
Conversation
json gains a formatting setting taking record-per-line, minified or indented, with the layout literals held on a style so the arithmetic that hits an exact byte count measures whichever one is in use rather than predicting it. The default is the layout this format has always written, pinned by two new golden values. The measurement that shaped this is a negative one: no reader can tell the three apart. The same records minified, one per line, indented by two and indented by four all parse in CPython's json and in V8. So the value of the setting is entirely outside the parser - a minified document of any size is one line and ends without a newline, an indented one holds about a third fewer records in the same bytes - and the structural checker has to be TOLD which layout to expect, for the reason the CSV dialect is told. That immediately falsified what the existing checker said about itself. It read "the manifest states one record per line" and counted lines against it, so both new layouts would have broken it. The sentence was not wrong - it stopped being true the day the layout became something a person can ask for. Each layout answers for its own floor: 216 B minified, 219 B a record per line, 318 B indented. The registry declares the default layout's, the generator answers for the rest, and the refusal names the layout it is about because the same size is legal in another. The canary is the half that makes the rest mean anything: a checker handed a file and the RIGHT layout name would pass even if it ignored the name, so the guard hands it every wrong one instead. Six pairs, six refusals. Six mutations, all caught - including one already in the list that this refactor had staled, which staleness.py found rather than a reader. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The engine gained property:json.formatting and neither parity list named it, so TestEveryEngineCapabilityIsClassifiedForBothSurfaces refused the run on all four jobs. That is the guard doing its job: a setting reaching the engine without anybody answering whether the window offers it is exactly the drift D1 forbids. The bar for the reachable list is two things rather than one - a control on the screen, and a guard that presses it and finds the value on the other side - and both were measured before the name went in. The field is drawn from the declaration and nothing else, the menu opens on its declared default and is named among the twenty that do, and the path from a field to the manifest is pinned by the guard that types a value and reads it back off the disk. One thing was worth asking rather than assuming. The window sends every setting, because a menu cannot be empty, so a run started there says record-per-line out loud where the command line says nothing at all. Those two have to be one file, and the guard that pins them already exists. D1 parity: 114 of 125 capabilities reachable from the window, eleven still to go. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
jsongains one setting:formatting, takingrecord-per-line,minifiedor
indented. It defaults to the layout this format has always written, pinnedby two new golden values.
The measurement that shaped this is a negative one
No reader can tell the three apart. The same records written four ways, on two
implementations in two languages:
jsonJSON.parseSo the value of the setting sits entirely outside the parser. Measured on our
own 64 KB files: minified holds zero newlines and ends without one,
record-per-lineholds 292,indentedholds 3419 - andindentedfits 201records where
record-per-linefits 290, so the same size carries a third lessdata.
It also means the structural checker cannot work the layout out for itself, and
has to be told, for the reason the CSV dialect is told.
That falsified what the existing checker said about itself
check_jsonread "the manifest states one record per line" and counted linesagainst it, so both new layouts would have broken it. The sentence was not wrong
for. Second time in one session that a comment had to be rewritten rather than
deleted for exactly this reason.
Each layout answers for its own floor
216 B minified, 219 B a record per line, 318 B indented. The registry
declares the default layout's floor -
MinBytesis one number - and thegenerator answers for the rest through
SmallestAccepted, the same split as theCSV dialect. The refusal names the layout it is about, because the same size is
legal in another one.
The canary
A checker handed a file and the right layout name would pass even if it
ignored the name entirely, so the guard hands it every wrong name instead.
Six pairs, six refusals.
Verification
gofmt,vetrefactor had staled, found by
staleness.pyrather than by readingThe whole local suite was not run for this branch - CI covers it.
🤖 Generated with Claude Code