Anyio integration (Trio support)

[uSpike]

To my knowledge, there doesn't currently exist a high-quality websocket library that can support multiple I/O back-ends such as asyncio and trio. Given the Sans-IO nature of this library, there's an opportunity to leverage the anyio library to support asyncio and trio with one implementation. It would also open the door for other back-ends which may be supported by anyio in the future, such as twisted.

https://github.com/miracle2k/trio-websockets might be a decent reference for this, since it is a version of this library ported to Trio, which is very similar to Anyio.

[aaugustin]

Thanks for bringing up these projects; I wasn't aware of them!

I've been meaning to write a Trio version of websockets but I haven't started yet. Using the native patterns of Trio would be an important design goal. I'd have to see how anyio fares in this area. If it attempts to make Trio look like asyncio, probably that won't meet my design goals.

[uSpike]

@aaugustin thanks for the response. Anyio uses Trio principles and is as close to the Trio API as possible, while (amazingly) working with an asyncio back-end as well. Anyio supports all of the structured concurrency concepts needed to write a library like task groups, cancellation scopes, thread execution, etc. Check it out!

[belm0]

I've been meaning to write a Trio version of websockets but I haven't started yet

It would be effectively reimplementing https://github.com/HyperionGray/trio-websocket -- is there something specifically wrong with that existing library?

And since trio-websocket is already on Trio, already has an API that considers cancel scopes and structured concurrency, porting to anyio would be straightforward.

[aaugustin]

I'm writing websockets for fun. Some people do crosswords; I do open source software. There's nothing wrong with solving a puzzle someone else solved before :-)

I wasn't aware of trio-websocket so I cannot usefully comment on whether it's right. It builds on wsproto.

A few years ago websockets got right some minor details that wsproto got wrong, but I believe wsproto catched up recently, perhaps thanks to new maintainers, so this isn't a concern anymore.

[belm0]

I'm writing websockets for fun. Some people do crosswords; I do open source software. There's nothing wrong with solving a puzzle someone else solved before :-)

Totally fine in and of itself, but the picture changes when 3rd party users of the software are involved. From the user's perspective, they'd rather have otherwise competing developers cooperate on a single high quality library [*], and not have to chose between two options in the first place. (Half will make the wrong choice in this game.)

[*] doubly so given the relatively tiny worlds of asyncio, trio, and anyio

[aaugustin]

they'd rather have otherwise competing developers cooperate on a single high quality library

That's true.

Unfortunately, several other Python projects related to WebSocket started after websockets gained traction, leading to fragmentation.

[belm0]

A few years ago websockets got right some minor details that wsproto got wrong, but I believe wsproto catched up recently, perhaps thanks to new maintainers, so this isn't a concern anymore.

wsproto does have its problems. I reported a significant performance regression last year, the maintainers don't seem concerned.

python-hyper/wsproto#152

[aaugustin]

I learnt about anyio (among other things) thanks to this issue, so I'm happy we had this discussion. However, at this point, I'm not seeing any action to be taken, so I'm going to close it.

Rationale:

• websockets already provides an asyncio implementation

• I'm planning to redo it on top of websockets' Sans-I/O layer; depending on asyncio is hard enough in itself; I don't want to increase complexity with an intermediary layer (especially one that attemps to masquerade asyncio as trio — some abstractions are going to be leaking — there's already quite a bit of leaking in asyncio)

• other projects already provide a trio implementation

• I'm planning to create one on top of websockets', but given the above, the only benefit of anyio is "maybe it'll add support for other backends"; this benefit feels rather speculative vs. the cost of adding a dependency

[aaugustin]

4 years later...

• I'm in the process of adding trio support
• I'm doing it directly rather than through anyio because I was more worried of anyio causing complications than interested in what anyio would bring, considering that I already have an asyncio implementation
• there's one benefit of an anyio implementation that wasn't discussed above and that we aren't getting: if a library wants to build on top of websockets and support any I/O model for its own users via anyio, it's easier for them to build upon an anyio implementation.