On Mon, Aug 12, 2019 at 3:58 PM Chris Angelico <ros...@gmail.com> wrote:
> 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. > sure -- which I presume is what the author of the "separator" parameter was thinking. But to bring it down to the specific topic at hand: If the goal is to provide a way to encode arbitrary precision Decimals in JSON, then you could: * (1) support encoding the Decimal type directly (my suggestion) or * (2) support allowing users to control how they encode JSON numbers (Richards suggestion, I think) or * (3) support allowing users to control how they encode any JSON type. Frankly, each of these is a simple option, but each is more permissive than the next. I suggest that the least permissive solution that address the goal should be used. But: (1) would not fully solve the OP's use-case. (2) would not solve the use case of people wanting to control the full unicode normalization (there's also escaping non-ascii characters that may require normalization as well) Because these are different goals. So what goals are trying to be accomplished needs to drive the decision. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/6MA7QXPNZTCXB7NOY6ATTPK3N55SKOL6/ Code of Conduct: http://python.org/psf/codeofconduct/
