async API?

[zerario]

For some stuff (also see #7) it would be helpful to have an asyncio API to use in place of the sync one. I have no idea how much effort it would be to make this work without having to duplicate lots of code...

[somebluecolor]

Yeah I tried async first, but the way the interface is written, it's incompatible (async def vs def). It would mean:

• making a new async http shocker lib
• adding a new http library (maybe aio?)
• updating the API factory to allow for an async shocker somehow

I thought that was probably a bit too much change for this PR (#7). It would probably be a major version change. For now, I'm just using a built in thread pool in the cases where all the shockers need to sync the same parameters. Everything else is synchronous

[zerario]

Yeah, I agree that would have been out of scope for your PR, it's just what reminded me that I had this idea at the back of my mind.

I think it would also be quite useful to write custom more complex scenarios in Python. While XToys is nice for that kind of thing, I would love to write things like my recent Hurry up script in Python instead. Being able to use this library async would be the first step towards that (the others being having a Python library for other toys I own 😅).

Your list of changes sounds spot-on. With #2/#3 I will probably need to rethink some of the (at least internal) architecture anyways, so that's the point where I planned to look at this as well.