Aymeric Augustin
Aymeric Augustin
Yes, that would be nice. As long as it doesn't exist in the library, I'd recommend against your first option. Your second option can be implemented quite easily with a...
Marking as a potential improvement.
I'm still somewhat skeptical that I want to provide this API at all. For a small number connections, this will do the job: ```python for connection in connections: connection.send(message) ```...
To avoid the risk of blocking on one connection — a risk that exists only in high-throughput scenarios where asyncio is clearly a better choice — one can do this:...
In short, you're expecting websockets to [tell retriable errors apart from non-retriable errors here](https://github.com/python-websockets/websockets/blob/f45286b3b2d54f8b79087b060858042b2488688b/src/websockets/legacy/client.py#L596) If memory serves, when I implemented the automatic reconnection feature, I decided to walk away from...
At this point I'm more interested in designing a good API than in a PR. I see two main options: 1. we make the decision of what is a retriable...
What API would you suggest and why?
Thank you for the suggestion. That's useful. I'd like to keep the API and implementation as simple as possible. Ideally, I'd like only one new argument, when your first proposal...
Do you think that this proposal would support your use case?
I'm also growing sympathetic to considering HTTP 4xx as fatal by default, as they're defined as "client errors", implying that the client needs to be changed before retrying.