A suggestion on how to support both sync/async web3 variants

[MrNaif2018]

Hi! Sorry for not following the issue template as it's more of a suggestion.

I am using async web3py and would love to see more things being ported. But from checking some pull requests I see that quite a lot of code gets copied over and over, so there are basically two copies of the same code (for example in the ENS PR). The code can get out of sync quickly. I have an idea on how to solve this, as I maintain my own python library with both sync/async variants myself. Of course it's way simpler, but still.

You could try to create an async-only version, and wrap all the public methods via a special decorator. This is how for example pyrogram library does this. I have ported and improved their implementation here: https://github.com/bitcartcc/universalasync

Ideally, if you have ready async implementations everywhere, you would just @wrap needed classes and it should all work. In practice I am not yet sure how would it work in a project of that scale.

How it works? Basically it detects the current environment, if it's running from an async function it returns a coroutine directly, otherwise it does it's best to execute a coroutine in a sync environment (there are a few cases: when event loop isn't started, when it's in a different thread, etc). From my automated tests it should handle all cases.

I know it's probably too late to suggest, but worth trying (:

What I miss in eth async implementation is some middlewares ported, especially the retry, filter and cache middlewares

[fselmo]

Hey @MrNaif2018 👋. I think it would definitely be ideal to not copy code where we can avoid it. I would be interested in seeing what this might look like and comparing performance... maybe for the next major version 🤔. I wonder too if at some point the library may just become asynchronous, when all of it has been converted, but that would take quite a push toward a hard deprecation of the old sync library.

This is definitely worth checking out. Thanks for the post. We are in the middle of some other things but I'd gladly review some PRs for retry, filter, or cache async ports. Otherwise we'll do our best to get those out soon too 🙂.

Let's keep this open for discussion on the async design 📈 👍.

---

edit: Tagging #1413 so we can reference this in that discussion as well

[fselmo]

Closing as stale. We have async support for arguably the whole of the library at this point. Unfortunately this did require separation of logic and quite a bit of similar code since static type hinting support essentially required that separation.

[MrNaif2018]

Yeah, makes sense. Also thanks for the suggestion, will see if I can somehow add that to my library (: