On Thu, 29 Aug 2019 12:51:04 +0900 "Stephen J. Turnbull" email@example.com wrote:
If there's a protocol for converting objects to JSON, people will expect it to work, pretty much as much as __str__ does, at least in the domain that they're working in. And frequently it won't, and the user will be surprised by an exception, possibly in production when encountering an unusual case.
There isn't a specific argument here. This is just FUD.
To me, it's analogous to the UnicodeErrors that have been the bane of Mailman development for two decades. Our parsers are supposed to just work on any email message, but somehow the users keep finding new ways to crash them. :-/
And that is related to JSON... how?
Worse, the __json__ method will *seem* to work when inherited by a derived class, but doesn't know to serialize essential information about that derived class. That's an error by the programmer of the derived class, of course, but it seems a very likely one to me.
We should probably ban subclassing from Python so that you feel better.
Perhaps NumPy and Pandas converting all their types to use the __json__ protocol will be enough that the majority of json.dumps users will never see another such Exception, and surely no data corruption in production. Seems unlikely to me, and the possibility of such problems should be considered when we think about the development burden we are imposing on library maintainers, and the risks to downstreams, of adopting this protocol.
Which "development burden" are we imposing on library maintainers? Library maintainers are free to adopt or not the __json__ protocol. There is no formal obligation.