Discussion
Async Python is Secretly Deterministic
arn3n: While not production ready, I’ve been happily surprised at this functionality when building with it. I love my interpreters to be deterministic, or when random to be explicitly seeded. It makes debugging much easier when I can rerun the same program multiple times and expect identical results.
frizlab: Interestingly I think things that should not be deterministic should actually forced not to be.Swift for instance will explicitly make iterating on a dictionary not deterministic (by randomizing the iteration), in order to catch weird bugs early if a client relies (knowingly or not) on the specific order the elements of the dictionary are ordered.
lexicality: > This makes it possible to write simple code that’s both concurrent and safe.Yeah, great, my hello world program is deterministic.What happens when you introduce I/O? Is every network call deterministic? Can you depend on reading a file taking the same amount of time and being woken up by the scheduler in the same order every time?
KraftyOne: That's the cool thing about this behavior--it doesn't matter how complex your program is, your async functions start in the same order they're called (though after that, they may interleave and finish in any order).
lexicality: Only for tasks that are created in synchronous code. If you start two tasks that each make a web request and then start a new task with the result of that request you will immediately lose ordering.
lilyball: This claim sounds vaguely familiar to me (though the documentation on Dictionary does not state any reason for why the iteration order is unpredictable), though the more common reason for languages to have unstable hash table iteration orders is as a consequence of protection against hash flooding, malicious input causing all keys to hash to the same bucket (because iteration order is dependent on bucket order).
whinvik: Is this guaranteed by the async specification? Or is this just current behavior which could be changed in a future update. Feels like a brittle dependency if its not part of the spec.
KraftyOne: It's documented behavior for the low-level API (e.g. asyncio.call_soon https://docs.python.org/3/library/asyncio-eventloop.html#asy...). More broadly, this has been a stable behavior of the Python standard library for almost a decade now. If it does change, that would be a huge behavioral change that would come with plenty of warning and time for adjustment.
saidinesh5: One more reason for randomizing hash table iteration was to prevent Denial of service attacks:https://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-rev...
12_throw_away: No, determinstic scheduling is not a property of async python.Yes, the stdlib asyncio event loop does have deterministic scheduling, but that's an implementation detail and I would not rely on it for anything critical. Other event loops - for instance trio [1] - explicitly randomize startup order so that you won't accidentally write code that relies on it.[1] https://github.com/python-trio/trio/issues/32
StableAlkyne: > but that's an implementation detailThat sounds familiar...https://stackoverflow.com/questions/39980323/are-dictionarie...
