I read through this blog post announcing the python SDK. Temporal Python 1.0.0 – A Durable, Distributed Asyncio Event Loop. This quote stood out: “Only deterministic asyncio constructs are implemented. So everything relating to subprocesses, disk/network IO, etc. will fail if invoked.”
I understand that the temporal supports many asyncio module constructs like asyncio.Event and asyncio.Queue.
Is there a master list of the supported parts of the asyncio module? It would be nice to cross check a list when determining if I can use some part of the asyncio module. It’s not immediately obvious to me when reading the python asyncio docs which classes or functions are strictly deterministic.
Not a single list because asyncio keeps getting new things added. We get a bit more specific in the README and we’re actually relaxing that to start including absolute time (Python 3.12 changed wait_for to work in terms of call_at instead of call_later, ug).
It’s not immediately obvious in all cases to us either, we’re technically a layer removed too, so it’s really up to which calls on the AbstractEventLoop the CPython asyncio library chooses to call for each thing. Here is the current set of event loop functions we implement. If Python calls something not there, it may raise a not implemented error. This is why Python 3.11 asyncio.wait_for works and Python 3.12 asyncio.wait_for doesn’t (well, until the next PR is merged), because they changed which event loop function they call.
Thanks for the response, that sheds light on why some asyncio constructs are supported and others not.
Do you think there’s some chance that a future version of python could make a previously deterministic asyncio construct, non-deterministic? Resulting in temporal supporting it on an older python version but not on a newer one?
Edit: I think that’s what you were saying here:
Python 3.12 changed wait_for to work in terms of call_at instead of call_later, ug
Because i see your custom event loop supports call_later but not call_at. Thanks
Unfortunately I do think there is this chance. This happened with asyncio.wait_for (though technically it wasn’t deterministic to non-deterministic, it was just switching calls to another call we didn’t support because on its face it was non-deterministic). But I think it will 1) be rare, and 2) will usually result in a not-implemented exception which will result in a task failure that will be obvious and fixable. But yes, since we have chosen to leverage asyncio, we accept the library as it comes.
