Canonicalize blaze server dshape formatting. #1361
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Non-Python clients (like JS) can get tripped up with different
formatting in dshapes.
For instance, small record dshapes, like:
are stringified by default on one line, but longer dshapes, like:
are stringified onto several lines.
This commit ensures that all datashapes are stringified in a consistent
way, regardless of the number of components in the dshape or the
dshape's overall string length. Again, this is motivated by non-Python
clients that expect a consistent formatting for dshapes.
This has little effect for Python clients, as they can simply re-hydrate
the dshape on the client side and interact with the DataShape object
API.
The server tests were modified to not compare the string form of dshapes
directly; instead, they use
datashape.util.testing.assert_dshape_equal()
.The long-term solution to this is to separate the serialization of
dshapes from their string representation. This would involve defining
something like
to_tree()
andfrom_tree()
for DataShape objects, andallow clients to represent the serialized dshape contents however it
chooses.