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

Port useful abi utility methods to public utils directory #3036

Open
fselmo opened this issue Jul 11, 2023 · 3 comments
Open

Port useful abi utility methods to public utils directory #3036

fselmo opened this issue Jul 11, 2023 · 3 comments

Comments

@fselmo
Copy link
Collaborator

fselmo commented Jul 11, 2023

We have many handy abi utility methods that live under the web3._utils.abi directory that could be made stable / public via our public utilities directory in web3.utils.abi. Something that comes to mind is a method like encode_method_call(fn_signature, params), for example.

Some of these could make more sense if they lived in eth-abi (maybe eth-utils makes more sense as mentioned below) and could be exposed through web3.py if desired, sort of like how the eth-utils methods to_hex(), to_bytes(), etc, are passed through via Web3.to_bytes()...

This seems like a low-hanging fruit since that logic exists internally in the web3.py library. Making it public and massaging it into methods that are easy to understand and use could go a long way.

@reedsa
Copy link
Contributor

reedsa commented Jan 10, 2024

I'm curious if we also want to consider moving abi functions that reside in eth-utils. They seem to be closely related to other abi functions, so keeping everything in one place (probably eth-abi) would be ideal.

Another option, which may not make sense, is to move all things to eth-utils and just deprecate eth-abi entirely. I'm not sure what value one has over the other to be honest. My guess is everything "utility" would be easiest to find under the eth-utils package. Just food for thought.

@fselmo
Copy link
Collaborator Author

fselmo commented Jan 10, 2024

deprecate eth-abi entirely.

eth-abi houses the implementation for ABI encoding & decoding. I think it's a reasonable abstraction to leave that to its own library / repository.

I wouldn't be against using eth_utils a bit more for "public" utils though if it makes sense to - even if we end up exposing it via web3.py where / if necessary. The distinction of what should live in eth-utils vs web3.utils is one that would be good to think about. If the answer is "everything" then we can just port useful fxns over to eth_utils and call that the public utilities.

@reedsa
Copy link
Contributor

reedsa commented Mar 14, 2024

In #1596 we decided most functions which deal with a contract's ABI belong closer to its context within Web3. We started releasing event and function helpers publicly via web3.contract.utils.

When other functions are exposed, consider whether it is a generalized util and might fit best in eth-utils or if an ABI is involved it may belong in web3.contract.utils.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants