Guido von Rossum
Here is the doc; the only method that allows override is default(), but this method is only ever read for non-standard types (so effectively an “afterthought” of a normal serialization, in a sense), so standard types like bool or int (and, importantly, subclasses that inherit them) cannot have their serialization be overridden properly.
(Aside: I see “bonkers” as a silly term, but rereading the sentence, I do understand how it could be construed as some form of attack: I apologize. My sentiment was more along the lines of “I tried this for so long and with so little success that I’m starting to think I am insane, or at least very, very stupid”. And, while I might try to defend myself from accusations of the former, I will make no such claims for the latter. 
)
David Lord
The idea would precisely be to bake the design of a simple (possibly limited) preprocessing method into the JSONEncoder class, so that it can be leveraged like default() is, for a “postprocessor that just handles unhandled types” (caricatural description, but bear with me). I think expecting new users to write their own (fast) preprocessor (for JSON-like structures that might be heavily nested) is not the best idea. The advantage of a design like default() is that it is pretty easy to get a handle on (ie, just write a bunch of “if isintance of X, return Y”, then raise the unhandled case properly). I think something similar should be done for a preprocessor.
Laurie O.
I did not know many of these, actually. Where I work, we tend to limit our reliance on third-party dependencies as much as possible; but I’ll definitely take a look at these, thanks !
Once again, my thinking is just to provide “syntactic sugar” for simple preprocessors in the standard json lib; but if you consider that the current json lib already has too much functionality, I can see why you’d disagree with my suggestion.
Inada Naoki
Instead of making JSONEncoder more customizable, I would like to provide toolkit for writing their own encoder. Since JSON is simple, providing str encoder and float encoder would be enough for writing custom encoder by themselves.
This seems like a fine solution to me as well. Not sure about the implementation specificities that you describe later though.