Switching to async?

[whiplash-0]

90%+ of time is wasted on waiting for network communication. Are there any plans to migrate to async architecture? There are already ideas how to turn pybit into async. Many official Python API (Binance, OKX) support async architecture. The whole world is switching to async

[dextertd]

Switching to async would introduce breaking changes for all sync applications that rely on pybit.

Our current codebase is built around synchronous logic, so maintenance of both requests and aiohttp codebases (or another async supporting lib) would be required. This means double the testing, routine code duplication, and double the maintenance required for the library. In many cases, a fully shared core between sync and async versions is not feasible due to how asynchronous flows and exception handling work. This would go against the philosophy behind pybit, which is supposed to be a lightweight SDK: README -> https://github.com/bybit-exchange/pybit/blob/master/README.md#about

Same issue in regards to WebSocket support; we'd need to maintain the code for two WS libraries within one project, since websocket-client does not support async operations. There are many different use cases for pybit and it's unreasonable to require all users to switch to async in order to continue taking advantage of new Bybit API features as they come out.

Anyone is free to fork it and build an async-specific variant. There is demand for it, and there exist two (#236, #240) PRs demonstrating this. But as a core change, shifting pybit to an async-first model doesn’t align with the project's current direction or priorities.

pybit tries not to overwhelm the user with too complicated a design or too narrow a scope. We purposefully don't manually hardcode all the types and field names. This is to keep things flexible and encourage the user to understand the actual data the Bybit API returns. Python is an entry-level language and pybit will stay accessible to beginners wanting to learn about crypto, Bybit, and Python. We welcome any forks wishing to work on this and remain open to re-evaluating the situation if conditions change.

[whiplash-0]

Thanks for the expanded answer!

Some of your points make sense, like supporting 2 APIs at the same time would be more complicated (even though there is no need to support them indefinetly, just for migration time as it's always done with any software or system [e.g Windows, other Python libraries, APIs]).

But what I don't completely understand: you're talking about switching to async architecture for end user like it's something really complex and requires deep knowledge. Whereas in reality it's really simple, just to add asyncio.run(main) and add await before function calls. It's that simple. And there will be no significant difference if a user still would like to use same as in synchronous apporach.

But it would be a significant difference for anyone who is trying to build anything a bit more complex. Threads are much slower in switching the context (GIL release) than async tasks. Large amount of time is burnt during waiting for network communication. This becomes critical, for example, when a user listening for updates from 200 pairs every 100 ms + having many other tasks.

I've tried to use forks especially from @Chenger1, but it doesn't work.

I think with time and progress switching to async architecture will become inevitable. Most of top exchanges already did it or doing it.

[Chenger1]

Thanks for the expanded answer!

Some of your points make sense, like supporting 2 APIs at the same time would be more complicated (even though there is no need to support them indefinetly, just for migration time as it's always done with any software or system [e.g Windows, other Python libraries, APIs]).

But what I don't completely understand: you're talking about switching to async architecture for end user like it's something really complex and requires deep knowledge. Whereas in reality it's really simple, just to add asyncio.run(main) and add await before function calls. It's that simple. And there will be no significant difference if a user still would like to use same as in synchronous apporach.

But it would be a significant difference for anyone who is trying to build anything a bit more complex. Threads are much slower in switching the context (GIL release) than async tasks. Large amount of time is burnt during waiting for network communication. This becomes critical, for example, when a user listening for updates from 200 pairs every 100 ms + having many other tasks.

I've tried to use forks especially from @Chenger1, but it doesn't work.

I think with time and progress switching to async architecture will become inevitable. Most of top exchanges already did it or doing it.

Hello. Updated my async implementation and have tested this code in production for a while. You can check it in PR #334