On Sat, Jun 29, 2019 at 9:02 AM Andrew Barnert <abarnert@yahoo.com> wrote:
On Jun 28, 2019, at 12:09, Chris Angelico <rosuav@gmail.com> wrote:
1) For all the different types of object that can be read (integer, string, JSON blob, etc), have a function that will read one, stop when it's done, and report both the parsed object and the point where it stopped parsing.
For a string, what does it mean to “read one”? Does it just munch everything, or until the end of the line (whether \n or universal newlines), or until white space, or just one character? Whichever one you decide is right is probably trivial to implement (value, _, rest = arg.partition('\n')), but unless the goal is “exactly what C scanf does” (in which case I’m not sure we need a whole protocol-and-wrapper thing), there doesn’t seem to be a TOOWTDI answer here.
The %s marker would accept everything up to the next literal text. So if you say "%s@%s", it would read up to the at sign. The second part of the proposal would be doing that, though; the "%s" handler would simply accept everything and return it.
Meanwhile, the json module can already do this with the raw decode method (although you to have to construct a decoder instance, as it doesn’t have a convenience wrapper like loads), and so can lots of other things (even stuff like struct.unpack_from), but they mostly have a wide range of inconsistent APIs. Maybe just having a consistent “val, rest = parse_one(source_str, type)” function that calls a dunder protocol type.__parse_one__(source_str) or accesses a registry that each module can add to (and users can customize), or …?
Yes, that's what I mentioned as being possible to hack around with JSON parsing, but it's not exactly an API, and it's something that could be done way better for other protocols too. ChrisA