-
-
Notifications
You must be signed in to change notification settings - Fork 260
Fix deserialization of unions #319
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
Fix deserialization of unions #319
Conversation
Collapses the child elements into one, without class heirarchy, mixins, etc This is a replaying of 2670d11 (first implementation) and 9f5b95a (a bugfix) onto the new `main-v.0.7.0`, modified for the refactored upstream. This should bring `main-v.0.7.1` up to par with `main` for the features we implemented in our fork (dropping our `Unset` implementation for theirs)
Add support for generating setup.py and the initially generated one
|
@forest-benchling sure thing, I'll make sure to take a look at them before then. Can you rebase open PRs against main so it's easier to see what changed? Also since I've decided not to go forward with #297, if this really does depend on that is it possible to separate them? |
Yes, I will try. Sorry, this will take some time because so much has happened in the meantime that the merge conflicts are a mess 😬 |
NOTE: this has merge conflicts, because it's based off the
benchlingfork. I just wanted to get it up for review for visibility, I will change it to be based offtriaxteconce you have bandwidth to review it.Depends on #297
Deserialization of unions in
from_dictwas not working properly, because it failed to account for cases where the union property isNoneorUnset. This PR adds explicit checks forNoneorUnset.In addition, the type of the value to deserialize was previously set to
Any, which was masking type errors. In order to fix these type errors, I introduced a new concept ofcheck_type_for_constructfor each property, which allows the type to be checked before attempting deserialization.In the future, I think we should refine the
try/exceptpattern; it's not good practice to rely on a catch-allexceptwhen trying to deserialize each type within the union, because we don't know what exception was actually raised.