Chris Angelico writes:
On Wed, 30 Mar 2022 at 15:11, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
The first argument [of scanf could] be any iterable of characters, and if an iterator it would leave the iteration pointer where it left off (eg, beginning of next line in 'sample' above).
Hmm, I'm not really a fan. To be efficient, scanf will need to be able to use core string searching functionality - str.index() is faster than simply iterating over a string and comparing character by character.
OK. That performance issue plus my concerns about how to make use of a generic iterable pretty in a loop convince me it's not a good idea, and if someone wants it later they can deal with those issues. I figure it will eventually get a C (or Rust ;-) accelerator anyway, but the pure Python implementation should be as fast as possible.
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(). 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.
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!