On Aug 13, 2019, at 01:04, Richard Musil firstname.lastname@example.org wrote:
Concerning the custom separators, and why the implementation supports them, I believe it is not actually about the separators themselves, but the whitespaces around them. When you generate JSON with an indentation, you probably also want some spacing after double colon or comma so it looks "pretty".
Yes. But this could have been done with, say, a whitespace tuple that includes just the post-colon and post-comma spacing, rather than letting you also replace the colon and comma themselves. Still, you could always pass “Q~¥” as the post-colon space (or even some characters that are Unicode whitespace but not JSON whitespace, to confuse everyone). Ignoring safety, it might be a bit simpler to use, but probably a tiny bit slower, and I’m sure someone would ask “what if I want a space before the comma instead of after” even though that’s a silly thing to want, and… My guess is that the separators solution was not the cleanest possible design that gave the best answer to every bikeshedding issue, but just the simplest design that avoided most of them.
Remember that this was designed pretty early, when nobody knew exactly what would be demanded of a JSON library. In hindsight, I think you could scrap separators, indent, and maybe ensure_ascii, because people only ever use them to produce either (a) typical pretty-printed JSON, (b) as-compact-as-possible JSON, or (c) JSON that’s as readable as possible for a single line that meets the standards of an entry in all of JSONlines, NDJ, and LDJSON. But at the time nobody could have known about JSONlines, or that 7-bit-clean pretty-printed JSON would never be useful, etc.