Once in a while someone says that "yes, you can do logic programming in PHP or OOP in Haskell". Maybe, but syntax is more than a nudge, it's a finger on the scales.
Once in a while someone says that "yes, you can do logic programming in PHP or OOP in Haskell". Maybe, but syntax is more than a nudge, it's a finger on the scales.
I'd very much like a source for that, because I don't feel like it's very hard to understand.
> syntax like "async def" and "async with" makes you feel like you do, and stuff like FastAPI encourages you to type "async"
FastAPI's docs tell you to use "def" if you don't know what you're doing. [1] says "If you just don't know, use normal def."
It's also pretty simple, I think. If your function blocks, use "def", and let FastAPI run it in a thread pool to avoid blocking the event loop. If it doesn't block, use "async", and take advantage of concurrent execution without needing a new thread.
https://lucumr.pocoo.org/2016/10/30/i-dont-understand-asynci...
I haven't read the post in detail though, thanks for the link! Seems interesting.
Because that's the correct way. print("hello, world!") will block for a very short time, so it's not worth sending to a thread pool.
> In fact most, if not all, of the examples in the tutorial use "async def."
That's again because they show the correct way to use async.
Using async correctly, when it applies is preferable to a synchronous function. The docs encourage you to do it if you know how, and if your use case fits an async function.
> So I don't think it's surprising if developers new to FastAPI tend to use async by default.
It is to me, because the docs are clear:
- if you know your function can be made async properly, make it so,
- if your function blocks, use "def",
- if you don't know enough to choose, use "def".
People who complain that the event loop blocks too often simply haven't read the docs well enough.
There are trade offs for either but I think a lot of people come to python and don't understand event loops and how they work get bitten by it.