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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Union type support #87
Conversation
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.
@ydylla
Thank you for the contribution! Sorry for the delay in getting back to you because it was a holiday in Japan 馃槈
I left review comments. Please check 馃憤
Yes I treat pyserde versioning as |
In my projects I do not treat 0.x.x specially. I start with 0.1.0 and then increase minor 0.2.0 for features and patch 0.2.1 for fixes. |
* passing union args per serde scope to rendered union function * spliting is_instance into multiple functions & rendering the correct one will be faster
Oh! I didn't know sember allows breaking change before 1.0.0 馃槻 Anyway, I will change it from 0.2.3 to 0.3.0 maybe after a few more MRs are merged. 馃憤 |
* is_instance takes some shortcuts to increase performance, like only checking the 1st element of lists * typecheck was only used in tests
To be more performant we just try to deserialize instead of checking types, this means the order of types in unions is important. More complex types should be tried first, otherwise simple types will prematurely match.
* use a typed dataclass as container for serde internals * removed more_types.py & the custom serializer code. Unkown type exception has now own function.
class inheritance caused overwriting of scope values
thanks tomlfile example, otherwise I had not noticed it
Codecov Report
@@ Coverage Diff @@
## master #87 +/- ##
==========================================
+ Coverage 87.15% 88.18% +1.03%
==========================================
Files 11 11
Lines 903 948 +45
Branches 187 203 +16
==========================================
+ Hits 787 836 +49
+ Misses 79 75 -4
Partials 37 37
Continue to review full report at Codecov.
|
Hi @yukinarit, I am not sure if you like 431c914 but I thought it would be nice (and cleaner) to use the serde scope like an actual scope, which contains all serde internals. This way we do not need several If you do not like it, it is no problem to get the union support working without it. So do not feel obliged to merge this. |
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.
Hi @ydylla
I don't mind replacing scope object with dataclass. I left a few comments in order to understand the intent of the code. Please answer to the question when you have time.
Thanks!
LGTM |
馃コ Thanks for the merge. |
No problem! Thanks for the contribution! 馃檪 |
This tries to add support for Unions with complex types like
UUID
orIPv4Address
.The basic idea is to use the code generation to add function for each Union the dataclass uses.
This union function then tries to serialize or deserialize the field according to the order of types defined in the Union.
The first one that works is used.
Using the code generation for this has the advantage that the user can influence the order of checks and that only types are checked that are defined in the Union.
Which should be faster, then always checking against all types that pyserde supports.
Currently, not all tests work. I have not found a good solution for nested Unions or container types within Unions, e.g.
Union[List[int],List[str]]
.We probably need some form of recursion.
Some notable other changes:
is_set
in compat.pyserde_scope
which I needed to pass it to the union functions.NoneType
asNone
. I think this broke thetest_union_optional
test, but I still have to look into it.@yukinarit If you have time, I would appreciate a review and your opinion about the general idea?
Also I noticed you increased the version to 0.2.3 so only at patch level.
Do you use semantic versioning? Then it should be 0.3.0 in my opinion because the new type support is a feature 馃槃.
Closes #60