[michaelmior]

> ultrajson ... will not work for un-serializable collections

So I can't serialize things with ultrajson that aren't serializable? I must be missing something in this statement.

> The verdict is pretty clear. Use simplejson instead of stock json in any case...

The verdict seems clear (based solely on the data in the post) that ultrajson is the winner.

[apendleton]

> So I can't serialize things with ultrajson that aren't serializable? I must be missing something in this statement.

This might not be what they're talking about, but I did run into what might be the same issue when looking at ujson before. The builtin JSON module lets you define custom serializations for types that aren't natively JSON-serializable; we had an application that did that with datetime objects, encoding them as ISO 8601 date strings. ujson doesn't support anything like that; you have to make sure everything is one of the JSON types already before encoding.

[kelseyfrancis]

> The verdict seems clear (based solely on the data in the post) that ultrajson is the winner.

ultrajson isn't a drop-in replacement, though, because it doesn't support sort_keys.

[michaelmior]

Fair enough. Although I'm not sure why one would want that behaviour given that there is no guarantee of ordering when a particular JSON file is processed with any other library.

[mdaniel]

I don't know what they do with it, but it's handy for writing tests against an expected JSON file: assert json.dumps(expected, sort_keys=True) == json.dumps(obj, sort_keys=True) # where expected was json.load()-ed and obj was produced by the function

[michaelmior]

I don't understand your example and why you wouldn't just do assert expected == obj.