On Aug 26, 2019, at 01:47, Richard Musil <[email protected]> wrote: > > I gave it some thought over the weekend and came to the conclusion that I am > not going to go further with it (where "it" means my or anyone else's idea). > The reason is that I totally lost any motivation. I however feel some more > elaborate answer might be due and I will try to give one.
I think this is a pretty good summary. But it’s missing something important. At least two ideas came out of the discussion that could actually get done: adding support for serializing Decimal values to JSON, and adding a different customization hook than the default function (whether that’s a __json__ method like simplejson’s for_json, or something different like a singledispatch function). It’s fine that you don’t want to commit the time to develop either of those ideas further. Neither of them are the idea you started with, and, even if they were, raising an idea doesn’t commit you to volunteering for all the hard work. It may be that nobody wants to do so at this time. But at the very least, it means that next time something related comes up, there’s a good history for someone to look back to. So, I hope you don’t see the whole thing as a waste of your time and everyone else’s. > During the discussion I realized that there were 3 aspects (of the potential > acceptable solution), proposed by 3 different persons, about which they were > quite imperative: > 1) It must use Decimal (Paul) > 2) It must check validity of serialized output (Christopher) > 3) It must avoid unconditional import of Decimal (Andrew) I think Christopher would be happy with Decimal serializing without runtime checks _if_ there were sufficient unit tests to prove that Decimal can never serialize anything that’s invalid JSON (except for nan/infinity, and then only if the flag is set). If someone else takes up the idea, I hope they push for that. (I suggested that validity checking for 3.x and then sufficient unit tests to remove those checks in 3.x+1 might be a way forward, but I’m not sure if anyone would want to commit to double the work just to get something in faster.) > I also realized that implementing this would not give me any advantage over > using simplejson, neither in the performance nor in the features, so it lost > also the practical aspect of needing it. This is important. Even if you come up with something better than simplejson, it’s highly unlikely to actually help you unless you can extract it into a backport that you can publish and maintain on PyPI, unless you only need the new feature for code whose release date is so far in the future that it can require Python 3.9. And at that point, it’s probably easier to get it into simplejson (or, if that’s not possible, to fork simplejson), get some experience with the feature in the wild, and only then propose it for stdlib inclusion. This is something most people don’t realize when they come to python-ideas with an idea. And, sadly, the way people end up discovering it tends to put them off from doing it at all, rather than encouraging them to do it in the way that has the best chance of success. _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/AH4UJLAWMBDPIZOXAXALACDRMDB3NESB/ Code of Conduct: http://python.org/psf/codeofconduct/
