Skip to content
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

Merged
merged 6 commits into from Dec 14, 2022
Merged

Conversation

Solpatium
Copy link
Contributor

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:

  • No _asdict method
  • Comparison with tuple will return False
    I am wondering if we should support these two 🤔 Let me know what you think.

I also added 2 utility functions: as_tuple and as_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.

@Solpatium
Copy link
Contributor Author

I have just got an idea that might work, please don't review yet.

@Solpatium Solpatium marked this pull request as draft December 13, 2022 12:30
@Solpatium
Copy link
Contributor Author

Ok, it won't work, dataclasses are a better solution

@Solpatium Solpatium marked this pull request as ready for review December 13, 2022 12:34
@codecov
Copy link

codecov bot commented Dec 13, 2022

Codecov Report

Base: 96.21% // Head: 96.20% // Decreases project coverage by -0.00% ⚠️

Coverage data is based on head (6fbda51) compared to base (d529cb0).
Patch coverage: 100.00% of modified lines in pull request are covered.

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     
Impacted Files Coverage Δ
starknet_py/utils/tuple_dataclass.py 100.00% <100.00%> (ø)
starknet_py/proxy/contract_abi_resolver.py 94.28% <0.00%> (-1.43%) ⬇️
starknet_py/common.py 100.00% <0.00%> (ø)
starknet_py/constants.py 100.00% <0.00%> (ø)
starknet_py/net/networks.py 100.00% <0.00%> (ø)
starknet_py/net/models/chains.py 100.00% <0.00%> (ø)

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.
📢 Do you have feedback about the report comment? Let us know in this issue.

@cptartur cptartur self-requested a review December 13, 2022 15:30
Copy link
Collaborator

@war-in war-in left a 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?

@Solpatium
Copy link
Contributor Author

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 👌

@Solpatium Solpatium merged commit b4b6eda into refactor/data-transformer Dec 14, 2022
@drknzz drknzz deleted the feat/tuple-dataclass branch January 19, 2023 14:52
cptartur added a commit that referenced this pull request Jan 23, 2023
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants