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 TupleDataclass #590
Add TupleDataclass #590
Conversation
I have just got an idea that might work, please don't review yet. |
Ok, it won't work, dataclasses are a better solution |
Codecov ReportBase: 96.21% // Head: 96.20% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## refactor/data-transformer #590 +/- ##
=============================================================
- Coverage 96.21% 96.20% -0.01%
=============================================================
Files 58 59 +1
Lines 2641 2664 +23
=============================================================
+ Hits 2541 2563 +22
- Misses 100 101 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
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.
Seems good 🥇 Just to be sure, it is breaking for the users, right? Is TupleDataclass.as_tuple
needed to compare TupleDataclass with a regular tuple?
Couldn't we override __eq__
to handle dicts and tuples?
I thought about doing that, but then realised that tuple won't know how to compare themselves to our dataclass. I checked and actually python prioritises custom eq, so it works 👌 |
* Add cairo type parser (#566) * Add ABI module (#571) * Add transformation context (#576) * Add TupleDataclass (#590) * Add cairo.serializer module (#593) * Add fix to nested errors (#599) * Feat/payload serializer (#601) * Add tuple serializers (#612) * Add struct & uin256 serilaizer (#613) * Add FunctionSerializationAdapter (#614) * Add cycle check in parser (#630) * Add serializer factory functions (#629) * Use new serializer in contract (#637) * Replace data transfomer in some modules (#642) * Replace data transfomer in some modules * Simplify structure in account * Remove more dependencies on data_transfomer * Remove string typed types in contract * Cover missing statements (#648) * Cover missing statements * Change deprecation text in felt.py * Update starknet_py/cairo/type_parser.py Co-authored-by: war-in <61014013+war-in@users.noreply.github.com> Co-authored-by: war-in <61014013+war-in@users.noreply.github.com> * Add missing dots (#652) * Deprecate data_transformer module (#654) * Add simple examples in documentation of serializers (#653) * Add test for complex abi (#663) * Support {low, high} dict in uint256 serializer (#668) * Support {low, high} dict in uint256 serializer * Replace ^ with ** * Add basic docs for serializers (#679) * Add basic docs for serializers * Add more docs * Adjust comment * Move abi and serialization to top level modules * Add TupleDataclass to api * Fix docs * Fix serializing example * Fix lint * Use header consistent with the rest of the api * Remove unnecessary pylint disable, unify disables * Update comment * Format * Update docs/guide/serialization.rst Co-authored-by: Kamil Jankowski <kamil.jankowski.x@gmail.com> Co-authored-by: Artur Michalek <artur.michalek@swmansion.com> Co-authored-by: Artur Michałek <52135326+cptartur@users.noreply.github.com> Co-authored-by: Kamil Jankowski <kamil.jankowski.x@gmail.com> * Apply suggestions from code review Co-authored-by: war-in <61014013+war-in@users.noreply.github.com> * Make deployer.py variables private Co-authored-by: war-in <61014013+war-in@users.noreply.github.com> Co-authored-by: Artur Michalek <artur.michalek@swmansion.com> Co-authored-by: Artur Michałek <52135326+cptartur@users.noreply.github.com> Co-authored-by: Kamil Jankowski <kamil.jankowski.x@gmail.com>
About
In data_transformer module we return
Result
class and pretend it is a NamedTuple. This can lead to some unexpected behaviour.The most important feature of NamedTuple is that it can be used both as tuple and a regular object. By using dataclasses with
__getitem__
and__iter__
we can replicate this behaviour.Differences
The differences with previous implementation:
_asdict
methodI am wondering if we should support these two 🤔 Let me know what you think.
I also added 2 utility functions:
as_tuple
andas_dict
to make sure the most popular flows are covered out of the box.Cool things
In the future when doing #492 we can easily subclass
TupleDataclass
to provide strict typing 🔥Other solutions
To be honest ideally I would just switch to using dicts as returned values from functions, but we would be missing spreading values like this:
x, y = result
. It would be a big breaking change and would make quality of life worse. I think using simple dataclasses is nice compromise: we rely on solid, well known implementation and offer some simplifications.Related issues
Closes #589.