-
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
Extend compatibility to C implementation of frozendict #37
Conversation
I wonder if we should be checking |
Co-authored-by: reivilibre <olivier@librepush.net>
I did some incredibly unscientific testing and saw that the try-except was faster than doing a IMO the PR as it stands is a definite improvement to the code and shouldn't regress performance for any of our existing supported frozendict versions. |
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 relatively happy to go with the above; it's hard to argue against the fact that it is a definite improvement (perhaps slow vs broken, with the existing case being pretty much unaffected).
We could determine which implementation to use at startup of course, which would be the best of both worlds, albeit more code to maintain.
For what it's worth, this seems like it would be a one-liner;
frozendict_using_c_extension = getattr(frozendict, "c_ext", False)
and then using this in the if
statement (if we're truly concerned about getattr
performance — I'd be surprised if this was a particular concern because it should just be a hashtable lookup).
I feel a little bit bad about constructing a backtrace, throwing an exception and catching it for every frozendict we serialise, but it's not clear when the C extension is actually used (installing frozendict on my machine doesn't use it by default), and furthermore we're already resorting to copying the dict, which will already add its own performance overhead.
Ah, good point. I was thinking about lifting the |
Fixes issue #36.
Background: some versions of
frozendict
contain a C implementation offrozendict
that was incompatible with our code. This PR adds logic to catch and handle those cases.