On Aug 15, 2019, at 10:23, Christopher Barker <python...@gmail.com> wrote: > > This is all making me think it's time for a broader discussion / PEP: > > The future of the JSON module.
I think this is overreacting. There’s really only two issues here, and neither one is that major. But nobody has shown any need for any of the other stuff. > * support for extensions to the JSON standard (JSON5, etc.) One guy saw a bunch of shiny new protocols (half of which are actually stagnant dead protocols) and thought that if the Python stdlib added support for all of them, they’d all take over the world. That’s not what the stdlib is for. Plus, most of them aren’t even JSON extensions, they’re other formats that build on top of JSON. For example, a JSONlines document is not a superset of a JSON document, it’s a sequence of lines, each of which is a plain-old JSON document (with the restriction that any newlines must be escaped, which the stdlib can already handle). There are multiple JSONlines libraries out there that work fine today using the stdlib json module or their favorite third-party package; none of their authors have asked for any new features. So, what should the stdlib add to support JSONlines? Nothing. Maybe a brief section in the docs about related protocols, explaining why they’re not JSON but how they’re related, would be helpful. But I’m not sure even that is needed. How many people come to the json docs looking for how to parse NDJ? > * support for serializing arbitrary precision decimal numbers Multiple people want this. The use_decimal flag from simplejson is a proven way to do it. The only real objection is “Fine, but can you find a way to do it without slowing down imports for people who don’t use it?” People have suggested answers, and either someone will implement one, or not. It might be nice to spin this off into its own thread to escape all the baggage. Going the other way and holding it hostage to a “let’s redesign everything from scratch before doing that” seems like a bad idea to me. > * support for allowing custom serializations (i.e. not just what can be > serialized, but controlling exactly how) Only one person wants this. And he keeps saying he doesn’t want it. And he only wants it for Decimal or other float-substitutes, not for all types. And it won’t actually solve the problem he wants to solve. If there were prior art on this to consider, it might be worth trying to design a solution that has all the strengths of each of the existing answers. But if no JSON package has such a feature, because nobody needs it, then the answer is simple: don’t invent the first-ever solution for the stdlib module. > * a "dunder protocol" for customization I personally don’t see much point in this, as it’s trivial to do that yourself. (I had a program that depended on simplejson’s for_json protocol; making it work with the stdlib and ujson was just a matter of writing a function that checks for and tries for_json, and partialling that in as the default function. We’re talking 5 minutes of work, and easily reusable in your personal toolbox.) But if people really want it, the only real question is what to call it. And __json__ seems like the obvious answer. And again, it seems like this would benefit from being separated out to its own small discussion, not being bundled into a huge one. > * what role, if any, should the json module have in ensuring only valid JSON > is produced? I think where it is today is fine. The allow_nan flag is necessary for interoperability. The separators option may not be the best possible design, but it rarely if ever causes problems for anyone, so why break compatibility? The fact that you can monkeypatch in a punning float.__repr__ or whatever isn’t a problem for a consenting-adults library to worry about. So this is only even worth discussing if the “serialize arbitrary text” feature is added. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Y2GEXSRH7GFBQB6AG3NBAEIZ6DWZVUYI/ Code of Conduct: http://python.org/psf/codeofconduct/
