When generating a default ETag for a resource, we were making use of

repr() and generating a hash based on that. This was fine when just

using Python 2.x, but given a number of differences in 3.x (ordering,

string prefixes, and other changes), we ended up with very different

ETags, and these differences weren't even consistent across the various

Python 3.x releases.
Instead of repr(), we're now just simply serializing using

json.dumps(), sorting keys to ensure order. This creates a consistent

representation.
It's worth noting that we're ultimately serializing to JSON twice, and

at the moment there's no getting around that. The response serialization

lives in a different part of the API codebase, and works quite

differently. Down the road, we may want to give more control over ETags

bo the response code that otherwise performs the serialization.

Unit tests pass on Python 2.7, 3.4, 3.5, and 3.6.