-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an API to choose the underlying JSON encoder. #25
Conversation
See #26 for the failing builds. |
This is probably ready to go, minus some CI issues. |
See matrix-org/synapse#7674 for how this would be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused, as we seem to use simplejson
in this library because we think it better performant than stdlib json
. Yet we're adding functionality to allow using json
as we in Synapse think it's more performant than simplejson
?
I'm guessing we're doing this so that the library implementation won't change from under other people using canonicaljson? Could we do that via a version bump of canonicaljson instead?
@anoadragon453 There's a bunch of conversation about this in matrix-org/synapse#7674 (comment), but the gist is:
We used to think this, the latest profiling done shows this to no longer be true. Let me know if that clears things up or not! |
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Ahh, I see now. We're not only worrying about other users of this library, but also old versions of Synapse. Makes sense 🙂
Yes, I was thinking we should just change the default in this library to always be stdlib json based on the new benchmark data, but I'm guessing that would be a backwards incompatible change. |
The standard library JSON on Python 3.5 doesn't handle bytes well, so...yeah it isn't backwards compatible. Hopefully we can do that at some point in the future! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That clears things up then. Thanks!
This is an alternative to #24, which allows for better backwards compatibility for a period of time. It lets libraries depending on canonicaljson opt into using a different JSON implementation.