How Python Asyncio Works: Recreating It from Scratch

Re:How Python Asyncio Works: Recreating It from Scratch by kodablah on Tuesday May 07, 2024 @07:42AM (#40284393)

Like many static analyzers in ambiguous situations, you have to decide whether the possibility of false positives is worth the safety. In this case I'd flag it knowing that it could be marked ignored as needed (same with open() if it was used).

I have toyed with a MyPy plugin to do this, but the arbitrary state storage/cache is a bit limited to do good call graph and function coloring (metadata can be on types but not functions). And there's just not many other good _extensible_ static analysis libraries. Language like Go have static analysis libraries that let you store/cache arbitrary state/facts on all constructs.

[ Parent | on HN ]

Re:How Python Asyncio Works: Recreating It from Scratch by guappa on Tuesday May 07, 2024 @08:29AM (#40284681)

You must also detect "too long loops"… which is dangerously close to solving the halting problem.

[ Parent | on HN ]

Re:How Python Asyncio Works: Recreating It from Scratch by kodablah on Tuesday May 07, 2024 @10:08AM (#40285627)

This and other similar CPU-bound operations may be unreasonable to detect at analysis time. I would encourage users to run with asyncio debug mode in tests to help catch these: https://docs.python.org/3/library/asyncio-dev.html#debug-mod.... Granted that's runtime, but there are limitations on what analysis can perform, it's just meant to help catch obvious issues.

[ Parent | on HN ]