The choice for lack of dict key encoding should be documented

[pjrobertson]

#100 gives a really good outline as to why you can't do something like:

json.dumps({<MyObject: Cool Thing> : 'string'}, cls=EvenWithACustomEncoder)

I think this fact (And the arguments against it) should be in the docs.

I'm sorry I can't provide any suggested wording or other ideas at this time. At the least, a sentence like this would suffice:

"There is no way to encode custom objects when they are used as dict keys, the reasons are explained here: <link to issue #100>"

[JBaldachino]

For what it's worth, I did find that despite the excellent advice there, simplejson could not meet my needs. Perhaps there was something lacking in my implementation, but I had trouble while testing different fringe cases. Worried that my work-arounds were becoming too convoluted, I switched this leg of our stack to serialize/deserialize using PyYAML, a more complicated but robust solution.

I agree that it would be good to at least document the limitation to save others time, and as such I proposed a small addition to the docs. Feel free to edit for style or expand, just wanted to help get the ball rolling.

[etrepum]

YAML is much more appropriate if you're looking to serialize arbitrary stuff in arbitrary ways. simplejson is limited by the very rigid JSON format, YAML is far more extensible (which is why there have been so many problems with it, especially with regard to security).

[etrepum]

If you're willing to layer additional semantics on top of JSON there are projects such as JSON-RPC or Transit. Note that these are still typically implemented with simplejson under the hood, but vend a higher level API.