[weberc2]

I guess I think of that as a feature, but I also write threadsafe code by default. It’s not an issue compared to our async python code. Someone calling a library that makes sync calls under the hood can block the event loop until the load balancer kills it. Same thing with CPU intensive tasks or just a lot of tasks on the event loop. Never mind the problems of async code in a dynamic language.

[int_19h]

> Never mind the problems of async code in a dynamic language.

Such as?

[weberc2]

Forgetting the “await” keyword and trying to use a variable which now actually holds a future/coroutine as though it were the awaited future. We write tests to cover those cases.

[int_19h]

An interesting point. But this could be mitigated in a fairly obvious way by requiring an equivalent of "await" that is basically an identity transform for future-returning function calls (i.e. if a call is returning a future, you must always either explicitly indicate that you're awaiting it, or else explicitly indicate that you want the raw future - a naked call is an error).

[weberc2]

That wouldn't solve the problem at all--at best I'm getting a marginally clearer error message. It doesn't help me (the programmer) remember (before runtime) that my expression is evaluating to an async function and not a sync function. Whether I get the runtime error, "invalid call to async function" or "future has no property 'status_code'" is of little consequence.