Generic Representation Issues

I’m trying to use this for snapshotting, but running into issues with GenericRepr and double quoting problems when asserting the match. I tried master since it appeared to have fixed this and run into a new issue, the GenericRepr isn’t used and instead it’s directly datetime.date(...) or Decimal(...). The problem with this is that these types were never imported to start with, so I run into type issues.

Is there a reason these are representations in Python instead of a multiline string representation like in Jest? Jest only handles formatting and compares the formatted objects which makes things simpler (e.g. does this string equal the other), while the complexity of this project seems a bit higher from equality checks.

[ygormutti]

Some cons of storing strings instead of objects:

• GenericRepr is pretty much a way to store objects as strings and it’s already implemented;
• If you want to store an object as a string other than its repr you can do it by using custom formatters;
• https://github.com/syrusakbary/snapshottest/issues/75 presents a scenario (using pytest hooks to compare complex objects) that seems harder to accomplish if we store things as strings; i.e. it’s harder to compare objects at semantic level if they are stored as strings

The only pro I see is simplifying the comparison code. I think they did it that way in Jest because in JavaScript you can’t override ==.

[yourbuddyconner]

I agree that #82 should have most of these issues solved. However, if @blakeembrey can produce a test case that fails consistently with the new logic, the argument of serializing down to a string certainly does have merit.

I’ll leave this issue open for the time being pending seeing those test cases.