Antoine Pitrou writes:
And it actually doesn't help as much as you'd hope in serializing, either, not for a decade or so, because most objects won't have a __json__ method.
By the exact same reasoning, you can believe JSON "doesn't help very much" because most Python objects don't serialize with it. There's no point in discussing such stupid and out-of-touch arguments.
Now, now, Antoine, you are not exempt from the CoC. But your logic is incorrect; you generalize in a way that I don't accept. Go back and read the tracker issue you cited. It's about surprisingly getting an Exception. 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. 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. :-/ (Not in quite a while now, but there is no proof of correctness yet either.) 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. 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. I repeat: to the extent that the protocol is adopted it will be very convenient for users of JSON. But I see risks as well. Regards, Steve