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.

The other day (actually before I posted my last reply), I went to core-mentorship list to get some ideas about how to continue. There was this thread about how people got their first contribution and while most were positive there was one post which kind of stood out because it described an unsuccessful attempt which finally led to parting ways. I realized there is no shame in that.

I came here with some rough idea about the JSON module features, but had no clue what are the "real" use cases, what are peoples' expectations, etc. This thread actually helped me to get more of the understanding and the insight. I thought I had a nice feature in mind, and was wondering what it would take to get it into Python. On the other hand, I did not have any other particular ambitions, like becoming a Python contributor.

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)

Originally, I thought that I could fulfill 2) and 3), without jeopardizing 1) (my opinion on 1) I already expressed), so I implemented the Python part and run some performance tests only to find out that my solution cannot compete in performance with Decimal solution because of the additional validity check and I could not promote it anymore. I am not particularly convinced that the validity check is really needed, but I understand why others are requesting it.

So the only way to continue seemed to be implementing 1+2+3 and I realized I really did not want to do it. One reason was I did not particularly "like" it, while it is not meant to be read as that I thought it was wrong to do it this way, I just did not really feel invested in those ideas anymore, the other was, that I was no longer able to argue about it,  because I had basically no idea, if the users really need full validity check, or if the cost of one time import of Decimal really overweights the performance hit of the heuristic for a lazy import, and had to rely on what someone claimed on some mailing list (no disrespect meant).

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.

So I guess I am going to leave my patch on github for a while, if anyone decides to go ahead with 1+2+3. It is not exactly a rocket science but could save some typing, or if you want to run some quick benchmark. If you supply it with dump_as_number=Decimal, it would behave exactly as the version with hardcoded Decimal (sans lazy import). One thing to note, if you choose to use Decimal for validating JSON number, you will need to handle the case where allow_nan is False, and check that Decimal does not serialized them (it does in simplejson as there is no check). Should not have a big impact though as allow_nan is True by default.

Richard