Ensure JSON representation is compact. #3363

[BERRADA-Omar]

Summary

this PR solves the issues mentionned here #3363

The following related issues could all be resolved together...

We should use ensure_ascii=False for more compact text representations.
We should use separators = (',', ':') for more compact list and object representations.
We should use allow_nan=False to disallow invalid Infinity and NaN representations.

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

[lovelydinosaur]

Yep, thx. ☺️

[lovelydinosaur]

I've just noticed this accidentally snuck in a private import.

@BERRADA-Omar would you be up for refactoring these tests?

We can test this against public API using httpx.Request(). Eg...

data = {...}
req = httpx.Request("POST", "https://www.example.com/", json=data)
assert req.content == ...
assert req.headers = ...

[BERRADA-Omar]

Hello, i'll make the change.

[BERRADA-Omar]

@tomchristie i see that this is already fixed ?

[lovelydinosaur]

Yes. Thanks, tho.

[Kludex]

This broke the test suite on Starlette.

ref.: Kludex/starlette#2773

[lovelydinosaur]

Thanks for the feedback.

[beliaev-maksim]

@tomchristie This PR not only adjusts the ASCII representation but also alters the default JSON separators. These changes lead to unnecessary modifications of JSON objects, resulting in altered validation hashes that broke some of our tests.

[lovelydinosaur]

Thoughts...

• CHANGELOG entry here is insufficiently emphasised. Not an API change, but nonetheless changes to representation-on-the-wire are likely to negatively impact teams in the short run, as evidenced.
• Unclear how we should improve evaluation process of trade-offs such as this one.

[beliaev-maksim]

@tomchristie More detailed CHANGELOG is a "must". While it won’t solve the technical issue, it will simplify the debugging.

When moving forward a codebase, tough changes might be necessary, that is obvious. However, providing a grace period for users can ease the process. E.g., you could introduce a warning in the codebase and maintain it for two minor versions before enforcing the update.
As one of the options.