On Wed, 30 Mar 2022 at 18:09, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
Chris Angelico writes:
I don't think, for instance, that json.load() promises anything about where it leaves an iterable; in fact, I believe it simply reads everything into a string and then parses that.
It would seem so, the only constraint on the source is that it support .read().
Yeah. Logically, it ought to be possible and reasonable to build a JSON loader that can consume a file progressively, minimizing memory usage (particularly if there ends up being an error). But that's not what happens.
It's also documented to assume a "file-like object containing a [single] JSON document" (brackets are my insertion). AFAIK, JSON doesn't define "document", and a "JSON text" appears to be defined to be a single JSON value (array, object, number, string, 'true', 'false', 'null'). If you take that seriously, then you might assume the file to contain exactly one value, and throw away any excess.
That is correct. The standard definition of JSON is that there is a single value (calling it a "document" just implies intent - it's the same thing as any other value, just that most people don't use json.load() on a file that contains the word "false"), with nothing else in the file other than whitespace. Although I have frequently made use of JSONDecoder().raw_decode(), which returns a document and the point where it ends. It still doesn't work with partial reads, but I've used it with chunked formats a number of times.
It would be worth supporting both byte strings and text strings, though, for the same reason that they both support printf formatting.
Ethan would show up in our nightmares if we didn't!
Actually, I'd like to see that. Nothing wrong with making one's nightmares more interesting. :) ChrisA