asyncio

[aspizu]

provide asyncio functions in addition to blocking ones

[TheCommCraft]

This would require aiohttp and websockets as far as I know aspizu ***@***.***> schrieb am Mi., 18. Juni 2025, 20:08:

…

*aspizu* created an issue (TimMcCool/scratchattach#438) <#438> provide asyncio functions in addition to blocking ones — Reply to this email directly, view it on GitHub <#438>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATCKMZTDTNKWPCMTFMIQLY33EGTLLAVCNFSM6AAAAAB7T2VFISVHI2DSMVQWIX3LMV43ASLTON2WKOZTGE2TONZWGY2TCMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[aspizu]

use httpx it has an async client

[faretek1]

should/would this be done as a separate submodule, a seperate repository,or a seperate branch? or something else?

[faretek1]

and then upload to pypi as sa-async or something?

[TheCommCraft]

I'd say a submodule just for async event handlers and also async versions of site classes in the same files as the blocking ones

[TheCommCraft]

If anything, I would have be an extra like pip install scratchattach[async]

[TheCommCraft]

I could create a milestone for this and you could create a pull request if you wanr

[faretek1]

aiohttp is faster than httpx, but is more cumbersome to use, and i dont think the difference is that significant.
if we are zo use httpx, it would be worth considering stopping using requests for the sync side of things.

Also, since async with httpx would require an AsyncClient to be used anyway, it might be worth partially restructuring the library to use requests.Session/httpx.Client objects instead of storing headers and cookies seperately. There could be a Session/Client object as an attribute of ever session object, e.g. with the name rq. so it'd become self.rq.get(url),or self._sess.rq.get(url). the only problem is data validation.

[faretek1]

n.b. scapi uses aiohttp

[TheCommCraft]

maybe we could create an internal api for creating api calls like with uplink but for async and sync simultaneously