Great video as always! I feel like something that could've been touched on is exactly why there's a different syntax for asynchronous for loops. For anyone wondering why, consider what the alternatives for awaiting the next value of an iterator would look like. "for x in await y" already has a use: awaiting on y to get a normal iterator, then looping over it synchronously. "for await x in y" breaks the normal syntax of for loops, and looks like you're awaiting on the object that the iterator is yielding, instead of awaiting on the iterator itself. Maybe something like "for x in async y" would work, but it seems less clear than just labelling the loop as async at the beginning of the line.
This is not mentioned in many teachings. The __await__ magic method is not mentioned in python's async/await teaching, so I have to read PEP 492 to understand what python is doing behind the scenes.
@@Jason-b9t Yeah, although the best way to define __await__ on your own class is to make it an async method. i.e. async def __await__(self): return await self.future
Thanks for a great video! Got here after reading about iterators and generators in Fluent Python. This video helps to understand why the Iterator protocol itself is designed the way it is.
It feels like FastAPI is almost the last thing that needs a beginner tutorial, but it certainly doesn't make it worse if there will be more advanced one. Im all in for advanced
When it comes to the section of rate limiting in this vido, I would argue that it is better to calculate the delta time, then check if it is > 0, and if so, call the asyncio.sleep(...). This way you don't call the function. It should not make a notisable difference, but I still think such things are worth thinking about.
Do you know about the view mode "Presentation mode" in pycharm? It is pretty neat to make videos with. Also I really liked this video. I'm already awaiting the next one :-)
I wrote a function the last day and I was ten minutes trying to work out why it wasn't compiling to bytecode. I forgot you need to write "def"... I lost the next ten minutes laughing.
Concurrent database uploads? How do we upload data that comes in concurrently (eg from a concurrent scraping). All the tuts write to CSV not a db, that's suboptimal for somecases. Any advise on writing data concurrently?
Your examples do `asyncio.sleep(0.0)` when `max_sleep_duration` is surpassed. It seems that it's not exactly the same as a nop, similar to how `time.sleep(0.0)` triggers a context switch. Might be worth to explore.
asyncio.sleep(0) basically allows asyncio to check its event queue. So if there are other tasks that need attention then asyncio will switch to those contexts. Once those tasks sleep (or wait for IO, or complete), asyncio will switch back to the first task.
Quart need some spotlight...it is the async version of Flask. Migrated to it last year and got zero issues so far. Another plus: the most important Flask extensions are working well with Quart. Can you please make a video on Quart?
@@aflous no it was for a webapp i'm building..initially was using Flask but then it couldn't handle concurrent users, I was really close to upgrading servers. Migrated to Quart, postponed the upgrade due to how well async Quart handles concurrency.
I grabbed the code from the github to play around with it and it didn't know what "Iterable" or "Awaitable" was until I added the imports. On a quick search I wasn't able to find that it is a new python feature, how did you get away without importing?
I'm pretty sure your code doesn't really provide a proper form of rate-limiting any API-calls, but rather only presents the results/awaitables "rate-limited". Usually rate-limiting can be implemented with a decorator, that defers the actual call to a function with a wait till the next free time slot. So a new task will only be created and allowed to run after some waiting. With your code every awaitable is most likely an already running task and could be executed to completion with enough awaits happening somewhere in the code.
So your code works when use_api() is a coroutine (as shown), but it wouldn't if use_api() were a normal function that creates tasks and returns an awaitable.
_sighs_ I wish I didn't have to save content. My image sourcing/profiling Discord bot has to download them, though, so it can pHash and examine the image/video's colors. So, it is well insulated should it throw exceptions, it has a cleanup task that cleans out old files in case there is something orphaned, and I have the folder things are saved in be its own volume on my VPS where it cannot possibly kill the OS by filling up the main volume. All said and done, though, it's nice to have a video on more async stuff. That's my bread and butter (though I typically use aiohttp for my client calls).
could you download them into a bytesio object? that's what i've done when i needed file-like objects containing things i've downloaded but didn't want to actually save them to disk
If you have a lot of data you need to send and/or receive through a network, USB device, or similar, the thing that usually causes the most delay is the network/device connection, rather than the CPU like you'd experience with heavy computations. That means that, for example, if you have an application where you need to download a large number of files from a server, if you don't do it asynchronously, your CPU is going to wait for each download to finish before starting the next one, meaning it sits idle most of the time while waiting for chunks of data to come in through the network connection, which is a big waste of time. Each individual download also probably isn't using up the entire bandwidth of your network connection, meaning even more time is wasted. That's the problem async operations (or threading, which is very similar) aims to solve, by allowing your program to start the next download even while the previous one isn't finished yet. That way, the CPU can send out all the download requests at basically the same time and get the full use out of the network connection and as much use as possible out of the CPU. Async (and threading) will NOT help with heavy computations. If your program is slow because it's having to do a lot of complex math or anything like that, you'll be better served by multiprocessing (although in that case, it's also probably worth considering using Cython or a C extension or perhaps just using a different language completely, although there are certainly reasons why you might not want or be able to do so, in which case multiprocessing may be very useful for you).
@@thunder____ yeah i usually use async only for non blocking purpose but it’s hard to imagine when async loop is really needed 😢 I mean I need to loop each item all through
Just my opinion, but the whole async/await ideas in Python and JS are simply hacks to make asynchronous programs look like synchronous programs when writing -- that is, it makes it easier to learn but at the same time hides the details from programmers, thus preventing them from learning and fully understanding what is going on In small toy examples like this it can make code look 'cleaner', but in actual complex products it is much better to design the applications as asynchronous _in structure_, not simply in spirit.
I agree, but at the same time, simplifying things such that a programmer doesn't have to learn what's going on under the hood is basically Python's entire mission statement (and I believe explicitly so, but even if not, definitely in practice). I'm personally not a fan of Python due to that fact (as well as due to the lack of static typing and lack of access to manual memory management), but there is great value in a tool that makes it possible for people to get things done without having to become an expert. Some people who aren't primarily software developers have a need to be able to write their own applications without needing to become experts in the field, so Python can be a wonderful tool for those kinds of use cases. However, for anyone who is or intends to become a developer as a career, I fully agree that learning how to do threading without this async syntax is very valuable. But at the same time, for those people, I also think learning at least one lower-level language is practically a must, especially with how competitive the job market has gotten recently. Being competent in both Python and C (or at least Go or Kotlin or *shudders* Java) will look a lot better on a resume than just Python (and/or JavaScript and/or PHP).
@@thunder____ as far as I understand, threads and async/await, despite both providing concurrency, do not do the same thing. While threads operate by having the CPU rapidly switching between multiple tasks, Python's asyncio is all within a single thread. However, please feel free to correct me if I am wrong.
@@amath3307 Yes, asynchronous is a form concurrency, but has merely the use of preventing waits to block the execution of other tasks and rearrange execution of tasks, if necessary. It isn't a way to run things truly in parallel, but that's what threads are for and you can combine those paradigms. Yet, with threading your code usually can be interrupted at any point and requires locks and atomic sections to make it work correctly in any case. With async you only interrupt on awaits and some async-API calls, but usually don't have to use locks or atomic sections to make things work. Every code fragment between between two interruptions is already guaranteed to run alone, because of the single execution thread.
@@amath3307 I actually was never sure async and threads did the same thing under the hood, but even though they don't, the functionality is quite similar and fits approximately the same use cases, so I stand by the substance of my comment even if my implication that it was just another way to write the same thing is not quite correct.
@@thunder____ Great point! I do think that making programming more fun and rewarding for new programmers is great, and in some way Python is more geared towards that then most high profile programming languages.
Please do not make a FastAPI tutorial. It doesn't need any more attention, and it's honestly not very good. If you'd make a tutorial on Litestar or Starlette though, that would be awesome.
@@MichaelBoratko Contrary to what its name suggests, it's not very fast. Litestar is 10x faster in my application. It is quite bloated and its documentation is somewhat cryptic on certain topics. It's also primarily made by a single developer who seems to have a bit of an ego issue, based on some questionable statements on the FastAPI GitHub page. Litestar feels much more based.
I'd actually pitch a sanic tutorial or at least a showcase of sanic to write (asynchronous) web applications. (imo) it's very pleasant to use if you're coming from / know Flask and has a thorough documentation 🙂
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Great video as always! I feel like something that could've been touched on is exactly why there's a different syntax for asynchronous for loops. For anyone wondering why, consider what the alternatives for awaiting the next value of an iterator would look like.
"for x in await y" already has a use: awaiting on y to get a normal iterator, then looping over it synchronously.
"for await x in y" breaks the normal syntax of for loops, and looks like you're awaiting on the object that the iterator is yielding, instead of awaiting on the iterator itself.
Maybe something like "for x in async y" would work, but it seems less clear than just labelling the loop as async at the beginning of the line.
Those flashbacks... Relatable, James.
"like the user name instead"
I can't even imagine how fun that debugging session was
It would be very interesting with a video explaining how async/await works behind the scenes in python.
This is not mentioned in many teachings. The __await__ magic method is not mentioned in python's async/await teaching, so I have to read PEP 492 to understand what python is doing behind the scenes.
It's generators all the way down
Theres a great video by David Beazley called "Build Your Own Async" and a great series by EdgeDB called "import asyncio"
@@skarfie123 need to check it out, thanks!
@@Jason-b9t Yeah, although the best way to define __await__ on your own class is to make it an async method. i.e.
async def __await__(self):
return await self.future
Love to Tom Christie, Kludex and other maintainers of starlette, uvicorn and httpx!
The red logging info feels like bad ux design to me
You are such a great teacher ! I hope to be as clear as you are when I'll try to be a computer science teacher !
Thanks for a great video!
Got here after reading about iterators and generators in Fluent Python. This video helps to understand why the Iterator protocol itself is designed the way it is.
This was a great video. Thank you for featuring Starlette !
And uvicorn!
That's an exceptional video, thanks! I'll keep it in mind for future reference
Yes, please, a FastAPI tutorial!
It feels like FastAPI is almost the last thing that needs a beginner tutorial, but it certainly doesn't make it worse if there will be more advanced one. Im all in for advanced
Absolutely fantastic video. Love it. And I'll follow your advice on storing arbitrarily large files and hashing usernames. 😄😁
you're soooo freakin' good at explaining things!
When it comes to the section of rate limiting in this vido, I would argue that it is better to calculate the delta time, then check if it is > 0, and if so, call the asyncio.sleep(...). This way you don't call the function. It should not make a notisable difference, but I still think such things are worth thinking about.
Do you know about the view mode "Presentation mode" in pycharm? It is pretty neat to make videos with.
Also I really liked this video. I'm already awaiting the next one :-)
It would be beneficial to see timings and performance benefits of different approaches.
I am gonna say something that will make the comment section jealous. I met James in person !
I wrote a function the last day and I was ten minutes trying to work out why it wasn't compiling to bytecode.
I forgot you need to write "def"... I lost the next ten minutes laughing.
Concurrent database uploads? How do we upload data that comes in concurrently (eg from a concurrent scraping). All the tuts write to CSV not a db, that's suboptimal for somecases.
Any advise on writing data concurrently?
This is the best AI played turorial!
Can we async the Dyson sphere construction?
We can built it, we have the technology
This sounds like a sequel to Buckshot Roulette for your foot
lol I would totally be the coworker that hashes the username. sorry
really love how Python can be so modular without making it too different from other similar modules... but I'm still too dumb to understand it all :')
Your examples do `asyncio.sleep(0.0)` when `max_sleep_duration` is surpassed. It seems that it's not exactly the same as a nop, similar to how `time.sleep(0.0)` triggers a context switch. Might be worth to explore.
asyncio.sleep(0) basically allows asyncio to check its event queue. So if there are other tasks that need attention then asyncio will switch to those contexts. Once those tasks sleep (or wait for IO, or complete), asyncio will switch back to the first task.
@@marckiezeenderso it's basically the same as a yield?
@@skillfulfighter23 Yeah, it's the async-await equivalent of a bare yield.
You also can be an IT humor department consultant.
i love this channel
It’s too hard for me!!!
Can async for be used to read from socket connections? I am struggling to find any code snippets for this.
Please include oauth in fastapi!
What are your thoughts on alternative async libraries, like trio?
Quart need some spotlight...it is the async version of Flask. Migrated to it last year and got zero issues so far. Another plus: the most important Flask extensions are working well with Quart. Can you please make a video on Quart?
Did you try Dash with Quart?
@@aflous no it was for a webapp i'm building..initially was using Flask but then it couldn't handle concurrent users, I was really close to upgrading servers. Migrated to Quart, postponed the upgrade due to how well async Quart handles concurrency.
@@pietraderdetective8953 I see. Wondering if it is any better than fastapi though? (which is using starlette under the hood)
I see "Big Encode" got to you....
Fantastic video!
I grabbed the code from the github to play around with it and it didn't know what "Iterable" or "Awaitable" was until I added the imports. On a quick search I wasn't able to find that it is a new python feature, how did you get away without importing?
Fixed, thank you! I didn't include all my local changes in the commit I pushed.
I'm pretty sure your code doesn't really provide a proper form of rate-limiting any API-calls, but rather only presents the results/awaitables "rate-limited".
Usually rate-limiting can be implemented with a decorator, that defers the actual call to a function with a wait till the next free time slot. So a new task will only be created and allowed to run after some waiting.
With your code every awaitable is most likely an already running task and could be executed to completion with enough awaits happening somewhere in the code.
So your code works when use_api() is a coroutine (as shown), but it wouldn't if use_api() were a normal function that creates tasks and returns an awaitable.
gimme that tutorial mate! In a series!
Yes, could make a fastAPI tutorial
🙏
discord gang
Thanks as always!
_sighs_
I wish I didn't have to save content. My image sourcing/profiling Discord bot has to download them, though, so it can pHash and examine the image/video's colors.
So, it is well insulated should it throw exceptions, it has a cleanup task that cleans out old files in case there is something orphaned, and I have the folder things are saved in be its own volume on my VPS where it cannot possibly kill the OS by filling up the main volume.
All said and done, though, it's nice to have a video on more async stuff. That's my bread and butter (though I typically use aiohttp for my client calls).
could you download them into a bytesio object? that's what i've done when i needed file-like objects containing things i've downloaded but didn't want to actually save them to disk
Getting some manor hash slinging hasher vibes here
what is benefit that can get from async loop…?
If you have a lot of data you need to send and/or receive through a network, USB device, or similar, the thing that usually causes the most delay is the network/device connection, rather than the CPU like you'd experience with heavy computations. That means that, for example, if you have an application where you need to download a large number of files from a server, if you don't do it asynchronously, your CPU is going to wait for each download to finish before starting the next one, meaning it sits idle most of the time while waiting for chunks of data to come in through the network connection, which is a big waste of time. Each individual download also probably isn't using up the entire bandwidth of your network connection, meaning even more time is wasted.
That's the problem async operations (or threading, which is very similar) aims to solve, by allowing your program to start the next download even while the previous one isn't finished yet. That way, the CPU can send out all the download requests at basically the same time and get the full use out of the network connection and as much use as possible out of the CPU.
Async (and threading) will NOT help with heavy computations. If your program is slow because it's having to do a lot of complex math or anything like that, you'll be better served by multiprocessing (although in that case, it's also probably worth considering using Cython or a C extension or perhaps just using a different language completely, although there are certainly reasons why you might not want or be able to do so, in which case multiprocessing may be very useful for you).
@@thunder____ yeah i usually use async only for non blocking purpose but it’s hard to imagine when async loop is really needed 😢 I mean I need to loop each item all through
I'm letting you know to make a FastAPI tutorial.
2:29 FastAPI! FastAPI! FastAPI!
APRIL FOOOOOOOOOOOOLS DAYYY
Please make a fastapi tutorial.
FastAPI tutorial please.
What a head
Just my opinion, but the whole async/await ideas in Python and JS are simply hacks to make asynchronous programs look like synchronous programs when writing -- that is, it makes it easier to learn but at the same time hides the details from programmers, thus preventing them from learning and fully understanding what is going on
In small toy examples like this it can make code look 'cleaner', but in actual complex products it is much better to design the applications as asynchronous _in structure_, not simply in spirit.
I agree, but at the same time, simplifying things such that a programmer doesn't have to learn what's going on under the hood is basically Python's entire mission statement (and I believe explicitly so, but even if not, definitely in practice). I'm personally not a fan of Python due to that fact (as well as due to the lack of static typing and lack of access to manual memory management), but there is great value in a tool that makes it possible for people to get things done without having to become an expert. Some people who aren't primarily software developers have a need to be able to write their own applications without needing to become experts in the field, so Python can be a wonderful tool for those kinds of use cases.
However, for anyone who is or intends to become a developer as a career, I fully agree that learning how to do threading without this async syntax is very valuable. But at the same time, for those people, I also think learning at least one lower-level language is practically a must, especially with how competitive the job market has gotten recently. Being competent in both Python and C (or at least Go or Kotlin or *shudders* Java) will look a lot better on a resume than just Python (and/or JavaScript and/or PHP).
@@thunder____ as far as I understand, threads and async/await, despite both providing concurrency, do not do the same thing. While threads operate by having the CPU rapidly switching between multiple tasks, Python's asyncio is all within a single thread. However, please feel free to correct me if I am wrong.
@@amath3307 Yes, asynchronous is a form concurrency, but has merely the use of preventing waits to block the execution of other tasks and rearrange execution of tasks, if necessary. It isn't a way to run things truly in parallel, but that's what threads are for and you can combine those paradigms.
Yet, with threading your code usually can be interrupted at any point and requires locks and atomic sections to make it work correctly in any case.
With async you only interrupt on awaits and some async-API calls, but usually don't have to use locks or atomic sections to make things work. Every code fragment between between two interruptions is already guaranteed to run alone, because of the single execution thread.
@@amath3307 I actually was never sure async and threads did the same thing under the hood, but even though they don't, the functionality is quite similar and fits approximately the same use cases, so I stand by the substance of my comment even if my implication that it was just another way to write the same thing is not quite correct.
@@thunder____ Great point! I do think that making programming more fun and rewarding for new programmers is great, and in some way Python is more geared towards that then most high profile programming languages.
FastAPI tutorial please
Subscribe and w8 4 tutorial! FastAPI
Come on Man!! there must be an easy way to solve this problem. This is like OverEng in steroid !!
Please do not make a FastAPI tutorial. It doesn't need any more attention, and it's honestly not very good. If you'd make a tutorial on Litestar or Starlette though, that would be awesome.
I agree with this
This is so surprising to me, FastAPI is my preferred solution! Why do you consider it not very good?
@@MichaelBoratko Contrary to what its name suggests, it's not very fast. Litestar is 10x faster in my application. It is quite bloated and its documentation is somewhat cryptic on certain topics. It's also primarily made by a single developer who seems to have a bit of an ego issue, based on some questionable statements on the FastAPI GitHub page. Litestar feels much more based.
It's not that Fast API is bad. It's that Fast API is built on top of Starlette. It also doesn't get the love it should.
I'd actually pitch a sanic tutorial or at least a showcase of sanic to write (asynchronous) web applications.
(imo) it's very pleasant to use if you're coming from / know Flask and has a thorough documentation 🙂
The head is horrid
0th
my laptop is faster than yours.
first?
Gratz
Awesome video, super clear and easy to grasp. Love it!