On Tue, 13 Aug 2019 at 11:40, Richard Musil <risa20...@gmail.com> wrote: > > But my proposal is not more complex. Implementing support for Decimal > requires exactly the same steps as implementing the support for custom type. > > 1) One has to recognize the type in the input data,
How do you recognise the type? For Decimal, you just check if it's an instance of the stdlib type. How does *your* proposal define which custom types are valid? > 2) Get the JSON representation, possibly by using obj.__str__(). If you're using str() then this is easy enough, agreed. But what happens when someone raises an issue saying they want a type that has different str() and JSON formats? Are such types not allowed? Or do we need a "JSON representation" protocol, which defaults to str()? For Decimal, again it's easy, we just use str() and stop. > 3) Check the output that it conforms JSON real number spec. For Decimal, there's no need as we know what the str() representation of Decimal looks like, so we don't need this step at all. For arbitrary types, we do. > The only difference is that in one case you need a kw to specify the custom > type, in the other, you need a Boolean kw to explicitly pull in > decimal.Decimal (to avoid unconditional import of decimal). See above for all of the *other* differences. And it's arguable that with Decimal, which is a known stdlib type, we could just support it without needing a flag at all. We could defer the import by doing some heuristic checks when we see an unknown type (for example, if obj.__type__.__name__ != 'Decimal' we don't need to do an import and a full typecheck). But even if we do need a boolean flag to opt in, that's not such a big deal. Whereas with the custom type option, someone is bound to say they want a list of types to support in the same call, etc. More maintenance complexity. > Then, the decoder already allows custom type, in parse_float, so having the > same option on the output seems to me better. The symmetry argument is valid, but IMO pretty weak without an actual example of a case that would benefit from the more general proposal. > I admit, I consider my proposal to be as complex as yours, and better > fitting, to what is already implemented in decoder. Hopefully I've explained why your proposal is more complex. If the benefits justify it, I wouldn't object to extra complexity, but you've still not presented a single example where your proposal allows simpler/better end user code than the alternative of just supporting Decimal. Nor have you demonstrated that your proposal is simpler to teach or explain. Without a motivating use case, I very much prefer the simpler approach. If you still think your proposal is as simple as just supporting Decimal, I don't know what else to say. We may just have to agree to differ, and I'll leave it to others to judge. If you write the code, and some other core dev chooses to accept it having seen my objections but not been convinced by them, then I'm not going to stop them. But I won't merge code implementing your proposal myself in that case. Paul _______________________________________________ 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/2UEQWZSJNDL5YWBFWTQTBHZZFTMEWLAE/ Code of Conduct: http://python.org/psf/codeofconduct/
