Thanks for this comment! I actually have never tried to yield from in an async generator before. It just never came up until now! I read that section of the pep and yeah it looks like the core devs may have backed themselves into a corner on that one, sometimes making the core parts of the language simple and functional makes it difficult to support these less common uses. It's certainly possible to make it happen but it would take a huge amount of effort by a very knowledgeable volunteer to implement it, so unless a demanding use case arises it may not happen this decade. Great idea for a video but i've proven myself not knowledgeable on the topic already, so I've got some learning to do first.

Hey there @osolomons, thank you for your comment! It's definitely interesting you brought up the absence of "yield from" in async generators in Python, as described in PEP 525. This kind of detailed, critical thinking is what we love to see. It indeed demands a comprehensive adjustment, which could open up a rich discussion. I'll definitely consider covering this in a future video as it adds value to understanding the nuances of Python. Stay tuned and keep those great suggestions coming!

Oh my! Well I guess this is somewhere between implementation detail and bug that would be very hard to fix. The variable name is ".0" which is not a valid name. Probably just a limitation of how comprehensions are implemented. Fun fact though, you technically can access the iterator in a normal for loop if it is tracked by the garbage collector.

expr = [1,2,3]
for x in expr:
y = gc.get_referrers(expr)[0]
break

print(y)
<list_iterator object at ...>

Great question @GanerRL! A simple way to think about this is that, in Python, the scope of the loop variable in a list comprehension is restricted to the expression defining the list comprehension. This contrasts to a 'for' loop, where the loop variable is functionally global to the rest of the function. For list comprehensions, Python does not leak the loop control variable to the surrounding scope unlike with a normal 'for' loop. So when you call `locals()` inside the list comprehension, it shows the loop variable as it's local in that context. But in a normal 'for' loop, this isn't the case. This design choice is intended to prevent errors and make list comprehensions more predictable. Keep those questions coming! Cheers! 😊

While the for loop is indeed equivalent to many of those other things, in Python (CPython) it just so happens that the semantics of a for loop are defined in terms of while, iter, next, and StopIteration, not in terms of those other things. This video is not meant to tell you to replace your for loops (as I mention in the video DON'T actually do this), but rather to show you what for loops are built out of.

Thanks for your feedback, @lamprospitsillou6325! You've thrown out some great suggestions. While this video was mainly focused on diving deep into the structure and quirks of `for` and `while` loops in Python, I completely recognize the usefulness and power of list comprehensions, `for_each` methods, `map` methods, and `filter` methods in Python. These are topics definitely worth exploration. Look out for future videos where I plan to cover these subjects in detail, to help us get that little bit better at Python every episode! Your engagement is appreciated! Don't forget to slap that like button an odd number of times 😉. Keep coding and see you next time!

As is shown in the video, the else is put there to express intent, not to be cleaner or shorter. The else after a try except unconditionally means what to do when no exception is raised, which is easy for a reader to understand. This code isn't particularly complex, so the other way is perfectly fine as well, it's just up to preference.

Hey @lucasvsl889, great question! The main reason for using `else` with the exception is to differentiate between the `StopIteration` raised by the iterator (which we want to catch and treat as a signal to exit the loop) and a `StopIteration` or any other exception that might be raised in the main body of the loop (which, if it happens, should be treated as an actual error). If we decrease the indent and wrap the whole loop in a `try` block, we can't make this differentiation. It would lead to catching any `StopIteration` raised, even those from the for-loop's body which unlike the iteration signal, is an exceptional scenario that we'd want to be aware of rather than quietly swallowing. In other words, using `else` with the `try-except` construct enables us to handle exceptions precisely and prevent potential bugs from being masked. Hope this helps clarify the reason behind this design pattern! Keep those questions coming, they're deeply appreciated.

I was going to give this as an exercise! I think these being able to do these things shows a great deal of knowledge of the language (even though we obviously shouldn't replace fors or whiles with the other). So great job!

Hey @alphanow4199, thanks for the comment! You're absolutely correct that you can use a for-loop to mimic a while-loop in that way. The early `iter` call with a `lambda` is a clever trick to get a conditional iterator! However, it really emphasizes the point I was making in the video, that while it's possible to creatively use Python's features to substitute a loop construct for another, that doesn't necessarily make it a good idea. This approach might confuse readers who don't immediately recognize the `iter(lambda: bool(, False))` structure, while a simple "while :" remains clear. However, on the fun side of things, seeing all the creative and unexpected ways to use Python's structures is one of my favourite things about the language! Keep programming and stay curious! 😊

The last example is intended to show that you can access the iterator within the body of the loop, which was accomplished by printing it. The intended behavior was not to print 1, 2, 3, but to print iterator, iterator, iterator.

Hi @ericecklund676, thank you for your question. You're actually viewing the memory location of the iterator object when you run print(it). The iterator object is not the list itself. Instead, it's an object that the Python interpreter uses to keep track of where it is in the list as it's executing a for-loop. Hence, print(x) can provide an output that's more immediately useful to the user, like the actual elements of the list. Thanks for paying close attention to the details and keep those questions coming! 😊

Hmmmm... you can definitely get rid of await and async since those are just wrappers around generators in Python (for now). Nonlocal might be avoidable using unique variable names. Theoretically try except finally raise could be avoided by rewriting everything to never throw exceptions but beyond that they would be very hard to avoid. I think you could get rid of except by always using try: finally and inspecting whether the current exception is set or not, but not totally sure on that one and it would involve accessing sys, which is not on your list. I think you might need to add exec as well, or were you able to rule that one out?

Hey @AByteofCode, interesting challenge you've set for yourself! While it's possible to eliminate some keywords by using other features of Python, doing so becomes unwieldy and unreadable very quickly. Some keywords, such as `def`, `while`, `try`, `except`, `finally`, `raise`, and `nonlocal`, handle very specific functionalities that aren't readily replaced by other Python language structures. For instance, the `def` keyword to define functions is pretty fundamental to structuring any non-trivial Python program. In any case, making Python keywords redundant isn't necessarily about finding a one-to-one substitute with other language features, but more about understanding the underlying concepts they represent. It really speaks to the richness of Python that you can manage to replace quite a few of them! Keep exploring, coding, and remember to always slap that like button an odd number of times!

Good point! There may be optimizations for some iterators that are written in C where they can optimize away the actual creation of a StopIteration if you don't observe it. But for even for builtins if you call next on an exhausted iterator a StopIteration is raised, and if you define your own iterator with a dunder next method, that method should signal that it is done by raising a StopIteration as well. So while technically I think creating a StopIteration can be avoided, I think that semantically it is still supposed to "be there".

Hi @ZeroIntensity, thanks for sharing your insight! You're correct that under the hood, the CPython implementation uses a mechanism based on the return of the `PyIter_Next(iterator)` function. When that function returns a null pointer, it signals the end of iteration. The `StopIteration` I was discussing is somewhat of a high-level abstraction that the Python interpreter presents to us, the coders. That being said, conceptually understanding `StopIteration` can help when you're writing your own iterator classes or debugging Python code. So, I thought it's an important point to cover. Always love to see keen programmers like you in the comments! Stay curious and happy coding! 🚀