On Tue, Aug 13, 2019 at 8:34 AM Christopher Barker email@example.com wrote:
On Mon, Aug 12, 2019 at 2:59 PM Chris Angelico firstname.lastname@example.org wrote:
On Tue, Aug 13, 2019 at 7:55 AM Christopher Barker email@example.com wrote:
That may mean the cat's out of the bag, and we can neglect any role of the json module to try to enforce valid JSON, but still...
The *decoder* will enforce valid JSON, but the *encoder* doesn't need to stop you from doing what you've chosen to do.
It doesn't "need" to, but it would be nice. Having an encoder/decoder that can encode things that it can't decode seems a bit asymmetric to me.
Perhaps the goal of the json module is to decode valid JSON, and to encode an arbitrary set of JSON-like encodings, but I don't *think* that is a stated goal of the module.
l'm all for practicality -- if there is a use case we want to support, and supporting that use case suggests a solution that allows shoot-footing fine. But if there is a way to support that use-case without the foot gun, then I think that's a better option.
It's more that there's no reason to go to great lengths to *stop* you from encoding invalid JSON. For it to block it, it would have to explicitly check for it, instead of simply assume that you aren't doing anything to break it. Permissiveness is the simple option here.