Python's creator wishes this feature never existed 

That's what I expected it would do as well. I've had a few times where I had a while loop and code I wanted to run if it didn't happen.

I agree that the else should mean that the loop body did not run. But the feature of running a piece of code if the loop completes is quite handy as well. And i do work with Python nowadays

I am .NET developer and thought the same. Would be nice to have this feature.

@@johnny_eth Why can't you just run a piece of code after a loop completes by simply putting it underneath that loop? Why would it have to be part of the "for" loop?

I wish people would retire the oxymoron "web developer".

Yeah, that would actually be a good use case and usefull feature decreasing boilerplate for handling empty collections and I'd love it implemented in e.g. JS, in which arrays are objects, and therfore are casted do true..

Interestingly, that would be the behavior of a Python loop with this configuration. Since the else clause happens when a for loop completes through the iterable (reaches a raise StopIteration rather than breaking before), and empty iterable would still call that and the else statement would execute. EDIT: He covers this in the video, I need to stop reading comments before finishing the video. lol EX: foo = [] for item in foo: print("in loop") else: print("done loop") In Python 3.10 expected output: done loop

if seq: for x in seq: ... else: But that doesn't work if seq is an iterable, so I would like this idea, but it probably won't happen.

Well, I figured out how you _can_ make the code work that way. The best way (IMHO) is this: if 'i' in locals(): del i for i in range(0): print("did something") else: if not 'i' in locals(): print("did nothing") Checking for and deleting 'i' before the "for" loop is *probably* the best way, because unlike C, Python chooses to keep its iterators after the "for" loop has terminated. However, Python does _not_ initialize the iterator if the loop never runs, so you have to check for and delete it if it does exist, and just hope that another variable by the same name didn't exist as an important entity somewhere else in the "locals()" library. Of course, if it did, the "for" loop would overwrite it anyways if the loop did run (I think), so how much harm have you really done?

That is actually how it runs. You're completely on the right track. Think about it, a for loop always checks for some condition before running again. For example: for item in list: do_something(item) means the computer is thinking IF there is another item in the list THEN i will preform an iteration on it. So next we can add ELSE i'll do something else. It is impossible to construct a terminating loop without the computer using some kind of conditional expression, be it a for loop or a while loop. Of course, you can have a loop that doesn't terminate, but those (while they do have some use) are generally undesired.

Future people trying to read your code won't be happy

@@thedopplereffect00 They can just learn the language. There's no need to code to the lowest common denominator, that's what java and javascript are for. *Iff* this is used properly, it is more readable than the alternative.

@@paulie-g in the real world I need to be familiar with about 4 programming language at once. I don't have time to memorize every corner case of every one of those languages. It's not efficient way to build software. Imagine a car that only needs 4 tools to build vs. 100. Which one will be more reliable and built faster?

@@thedopplereffect00 I write many more than that fluently. It's not hard.

@@paulie-g you act like every programmer can be in the top 1%. No way everyone is going to memorize 20 years of C++ changes along with proficient usage of several libraries. We all have limited time.

Without the rename I would vote for not using it. Python is very proud of being a language that is easy to read and "else" at the end of a loop makes no intuitive sense

You can also do this in one line with a generator, next, and its default argument E.g. to find the first odd numbers in a list nums: odd = next(num for num in nums if num % 2) throws a StopIteration if there is no odd number in nums odd = next((num for num in nums if num % 2), None) sets odd to None of there's no odd number in nums

@@georgplaz It's only unintuitive for those who don't know what it is. Although python is easy to read even for those who don't know it much, it has a list of "advanced" features that you have to be familiar with in order to understand what's going on. This is just one of them, imho a pretty useful one.

@@sshilovsky "It's only unintuitive for those who don't know what it is." If someone knows what it is, then it's a bit past being intuative or not lmao.

@@joseville this would only return %2 of the first number, and next doesn't have kwargs odd = next((num for num in nums if n%2), None)

fancy seeing you here lol

@@NOT_A_ROBOT oh hi

GOTO

hey! it's that one tetris person

@@jessveness hello lol surprised anyone knoes who i am

Did it do what you expected it to do?

@@shahram6869 Yes

what use case can exist for a for-else that is not the perfect use case for a while?

Same here. Although the name is really unintuitive.

same! but as above, it's not really an "else"!

the definition makes sense when you think about it in terms of the else in the phrase "what else?" which usually means "what more?" you ask someone/the computer to do a bunch of things and the computer goes "what else?" and you say else: this

Using less statements doesn't make you a better programmer. Using obscure unintuitive hard to read language features certainly isn't gonna help you

@@austinbryan6759 Well it's only obscure because no one knows about this handy feature. Now we do. And for redability, simply adding a comment: # following code executes on exit. Increases redabily by 1000%. Comments: Use them. :) Or maybe we can create a function in a different file (module), put it in a class add OOP philosophy, do an import and refuse to put comments like a Boss...

@@Boehoehuahoei TBH, I think the only reason it's obscure, is because it simply isn't brought up in a large portion of tutorials/books. It might just be me, but the guide I learned on used them in many examples... so I just use them in many of my loops. As far as readability. I actually feel it makes code more readable in the case of exceptions, than just returning/indenting the return. Perhaps it's just me coming over from C, but that little extra step of structure to the code makes it easier for me to read.

In both cases the intent would have been clearer if the keyword was "finally", not "else".

You should make it clear in interviews of something weird like this, much like you should put a comment where you do something weird like this so someone doesn't go "wtf?" and delete it (or indent it to match with an 'if'). It would show you know how to comment your code properly and be a big plus in an interview.

as far as I understand, the while loop stops if its condition is not met, and by analogy with if, the code continues in else. But if you stop it with break, the condition is still (with a few exceptions) true, so else is not executed. and it's stupid to come up with a separate keyword for for loop

The name is confusing. What if I want to run code in case the loop was never entered? What tells me that a break jumps to the else branch and not beyond it? What it does is useful though.

I got to know it looking for a way to avoid having to use a flag variable. For me, the interpretation was always that the else belonged to the if statement inside the loop (if reason_to_stop: break). The indentation levels don‘t match, but in my head that‘s because the else counts for all iterations of the if statement at once. I acknowledge that the “actual“ meaning is something else, but this approach actually makes more sense to me.

Time to learn about it... _finally_.

Just did, and, from on top of my head, I don't see much of a benefit to having it besides for putting the "except" block closer to the code that threw it 🤔

​@@guiorgy The benefit of the else clause is, that the try clause can only contain the line of code where an exception is expected. Other code that should be run if no exception is found can be placed in the else clause, therefore, no other errors/exceptions would be catched accidentally.

It's quite useful. Try stuff() except: it didn't work* else: it worked* finally: always runs, good for cleanup *Assuming you used/caught the relevant exception(s) properly

Goto is cleaner regardless. What macros would you ever need?

@@syockit Whether using macros or not, the trick with gotos in C that I really like is that this is legal: if (0) target: { ... } With that, you can have a goto target that is only reachable with the goto, which eliminates some of the traditional mess associated with gotos. It also makes it doubly obvious to anyone not expecting a goto that something odd is going on.

Doesn't that depend of what is in the "else"? Production code will have a colossal amount of code inside the "else", I'd much rather see a properly named function that basically describes itself instead of the "else".

@@ran_red I don't get why production code would have "a colossal amount of code inside the else". My last usage was to just notify, that collected enough data, some cleanup and exit. For sure it depends on use case. You should use a tool that makes your code more readable :)

Zig has the while else and for else as well. They can even be used to turn loops in expressions instead of statements. I find it useful in some cases

why unreadable code? if the function has a good name, I find it often makes code easier to read to put functionality in separate functions (unless the function then needs like 10 parameters)

@@georgplaz I found it easier to read script-like code than reading a lot of 2-4 line nested functions.

if you have to lookup what it means, you know the name has been chosen really poorly

@@georgplaz Why is that? Do you say the same for Kotlin's let, apply, etc. I had no idea when they meant but they are amazing tools of the language.

@@dhkatz_ Because it's unintuitive, and once you read what it does, the phrasing still doesn't make any logical sense. Run and apply on the other hand do.

@@georgplaz What a stupid thing to say. As if you don't need to learn the language in order to use the language.

Think of it as the Else to the If statement of the conditional for the While. It'll run if that conditional is false.

If you have a loop longer than 20 something lines, you're doing it wrong entirely

@@duckner - obviously, it depends on what you're processing; sometimes you need to loop on heavy work that may or may not need a break.

@@MindlessTurtle no, break it down into functions if it's that long

@@duckner - I don't know, sometimes I'd rather have a long loop than a dozen functions with tons of parameters. Really depends on how convoluted your logic can be.

@@MindlessTurtle that's unreadable and hard to maintain in almost all cases

if allowsMeToAvoidOneMoreVariable == true or oneLessLineOfCode == true: print("I'm going for it") else: print("I'm not using it")

@@yugix_1 not usingCamelCase is less_readable_than_snake_case

I might have used "then:" instead of "else:" - "do the "for/while" loop, *then* do this (unless you broke out)"

@@BarryRowlingsonBaz I'd have to agree, " then" is definitely a better keyword than "else", because IMO "else" only works in while(evaluation) loops, where it's sort of short hand for: do if (evaluation==True) do one thing; else do another thing; break; end do But in a "for a in list:" context "else" seems really off, after the list is fully evaluated the loop should end, it doesn't feel like there should be an "else" clause. That being said, this is incredibly incredibly useful because it comes up pretty often, e.g. in cases where you're searching for the first occurrence in a list and don't know if it's even in there. I think the following example is much more legible than any other way: # insert in sorted list for pos, num in enumerate(sorted_list): if to_insert < num: sorted_list.insert(pos, to_insert) break else: sorted_list.append(to_insert)

wow. I hope i never use it

Well thanks you sir ! Since i don't do Python my first thought was "why don't you do it recursively ?" and now i know better if some day I have to code some Python

Also I think functions that are only called at one place aren't always the bastions of legibility that people think they are. The for else statement is pretty useful and plenty legible. I think people are just hung up on the fact that python does a thing that no other language does and therefore that makes it illegible, but if that were the case people should also be against list comprehension, or really just the way for loops work in general (looping over a list rather than the C three argument for loop).

If I'm reading someone else's code, I rather see an extra flag there. You don't need another function, just about 3 extra lines of code (probably less total characters than that comment you'd trade it for), and the flag is probably named after what it's for, so it takes just about zero brain effort to unpack its meaning. Python is the odd one out with this kind of thing (among others), and so on top of the above, that means people who code more often in other languages, or people who ditched this practice into oblivion, will have to stop to think about wtf you're doing there; maybe even have to waste time googling it. I mean, it's not even semantically obvious what for-else or while-else is supposed to mean.

@@skaruts sure but you ignored half of what I've written: with a comment that explains what else does (just like Muprhy did in his video). In any case it's a topic subject to opinionated arguments.

@@unperrier5998 I have to really wonder if YOU ignored what I wrote, because I addressed pretty much everything you said, and you're kinda sounding like you missed my points.

@@skaruts I don't think I have. You said you like seeing a flags. And I replied that the else construct is superior when you add a comment remaining what the else cause does. If we follow best practice, as explained here for example ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-rrBJVMyD-Gs.html then 3 extra lines of code is about a third of the size of the function. Personally I prefer without a flag but I also understand you prefer flags. That's why I wrote it's an opinionated topic, because it boils down to personal preferences.

@@unperrier5998 ​ and I addressed that. I'm not speaking from opinion: the 2 (not 3, actually) short lines of flag code will take less brain effort and less characters than a comment, be self explanatory, etc. mCoding actually hit the nail in the head at the 3:38 segment. 99.9% of the time the else is redundant.

U write bad python then. Har har har.

A lot of time? Isn't that a little exaggerated?

@@brdrnda3805 nope, it depends of what project i'm working on. but most of the time it helps me save literally ton of time.

just put an if statement before the loop

​@@emiljohansson7574 That only works with stuff like array, list or dict where you already have everything in place and you can count or peak.. It won't work with generators (e.g. list comprehensions or yielding functions), and likely won't work with anything using async for either.

I use it all the time when I need to find the first occurrence of something in a linear list and I don't know if it's in there. For example, inserting a value at the correct place in an already sorted list. If it's not the biggest value insert it at the right place, if it is the biggest value insert it at the very end. Another great use of it is in crawling through XML files.

If you think of the elements being iterated over as inherently parallel, you wouldn't think of the loop as something with a counter and more in terms of a vector multiplication. (SIMD in assembly.) The idea that there is a check after every element is no longer intuitive then. In compiled languages the compiler would remove it if possible by unrolling the loop. Functional languages use things like filter, map, and reduce to iterate over lists or list-equivalent things, the check is implicit in that an empty list doesn't need to recurse further. An "else" would be unintuitive because either there is no "if" or if there is, it is in a different scope and does something already. So the "else" after the loop really only makes sense if you grew up with C or Fortran, and neither of those has that feature themselves: If you think of code as constructive proof of a mapping between the input and the output, rather than a serial sequence of virtual steps, it stops making sense even then.

My mental model for it is that it treats the loop as a kind of "find" operation, and the "else" executes if it didn't find the element you want (i.e. if you didn't break or return)

Imagine your code has a heat map, where lines of code are hotter if they are executed more frequently, and not so hot if otherwise. A hot loop is basically a loop that is iterated many times, and thus it is morely likely to affect your performance, because you are effectively executing one part of the code many times, and any small differences can add up to make a big difference. James was referring that the flag variable assignment may slow things down in a hot loop, because that's at least one more assignment step to do than the for-else counterpart.

Basically, a loop that iterates a lot, really quickly. Imagine iterating through each pixel of an image, then the innermost loop is a "hot loop"

@@NicolasChanCSY Thanks for the info!

Or just don't have it. It's behavior is too obscure for pythons readability gosls

@@squishy-tomato #define nobreak else 😁😁

I also know the pain. It was the day I had nested three loops and had to check which of those I had hit break in that I finally gave in and used goto's instead of an army of flag variables.

this video is not about try/except/else. in this case, the else makes intuitive sense

He literally says in the video that try-except-else is very useful.

It kind of makes sense to me given the context of try/except/else. Just like the "else" clause of a "try" block, which runs if the "try" exits without producing an exception, the "else" clause of a loop runs if the loop exits without breaking. It's not something I've ever felt the need to use, though.

Logic like this should definitely be put into a well named function instead of being buried in the implementation of something else imo, so I would rewrite it as: def retry_something(something, retries=1, delay=0.1): for _ in range(retries): try: return something() except Exception as e: print("something didn't work, trying again") time.sleep(delay) print("something didn't work after some retries. handling this case") ...

you can use a package called retry

@@LittleLily_ totally agree! I just wanted to see if this is an anti pattern or if i just found the one true use case for "for ... else" Anyway, i just found the library tenacity which does exactly what i need with a decorator. Pretty neat.

@@MrTyty527 true, although it's not maintained anymore. So tenacity is the better choice :)

That's a miracle, that this answer was accepted.

... So something like: for x in constants: for eq in equations: if not eq(x): break else: Print(x) break

@@zecuse something like that. The outer loop had values of the constant, the inner had xs in a certain range that I wanted to check. If all x values fit, the constant was considered suitable.

@@georgegerasev8874 it executed in less than a second and was simple to type out. It's not like your code is reviewed there, you only have to get the answer right.

Don't they just do a jump (So, a go-to) in ASM as well?

@@sebastiangudino9377 Sure, an assembler jump could be expressed as a C/C++ goto, but I skip the step of the goto-construct when imagining how a loop will translate to assembler.

Yeah I can understand not using while ... else but I think for ... else is very readable when you're specifically searching in loops and you **don't** want to break it out (very funny) into another function.

They could've used contextual keywords, where it's only a keyword if you use it in a unique context that you wouldn't use an identitifier. C# has like 100 or 200 keywords with contextuals without breaking any code

​@@austinbryan6759 Building a context aware parser is an order of magnitude harder task than a context free parser and benefits rarely outweight the increase in complexity. Also, context aware grammar will make it much harder for text editors to implement proper syntax highlight as most of them do not do real parsing and instead use simple regex matches (or even just highlight all words from keywords list as keywords).

Django (and Jinja, I think) does exactly this. for...else means "for each...but if empty, then instead..."

You for about while-switch loop shenanigans :D

@@yaroslavpanych2067 Duff and his stupid Device are not worth the headache unless you need every cycle and even then the compiler’s probably better at optimizing it than you are.

that would be cool. one issue is that return means returning from the function and not the loop (in all languages I know), so maybe another keyword would be better

Thinking this more, another idea on how to do it would be to have this returning loop be "from". x = from x in y: if x == 2: return True else: return False

@@zokalyx You could just treat it the same as function def, its own namespace etc. Like, if you define a function inside a function, you can't exit from parent function from inside the child function

In my opinion functions should either be for things that you need to do more than one place or for complicated self contained things. Using a function call instead of a for .. else .. is much more illegible to me, especially when doing things like recursion or building an algorithm. In these situations self contained functions are much nicer to me.

a 'yesbreak' would be fantastic for getting out of nested loops

I wouldn't call them 'dangers' as they don't cause incorrect execution. Python has a strong culture of writing clear, nearly self-documenting code, and is usually taught this way, so you see better results. It's important to teach the principle, and demonstrate it with code in popular projects. Real programmers (not monkeys and hacks) will figure out on their own how to apply the principle, so dogma is unnecessary. I'm still not a fan of widespread hidden-code or hidden-control-flow usage, eg decorators, unless they're absolutely necessary. I learned Python one day long ago because I needed to write something on top of Twisted (a monitor for a master-(n)slaves db system). It took me a couple hours to run through the syntax, then I read Twisted's reactor code to make sure it was using epoll properly, a few protocol implementations, and understood *everything*. The readability is what sold me on the language (I had been prejudiced against significant whitespace beforehand), and I dare say that's true for a lot of others. I had a fully working bespoke async monitoring system with web interface ready in 2 days, from knowing none of the language or a complex, fully-featured framework in Twisted to feature-complete and stable. Clever programmers in perl compete to write the most terse, unreadable code; clever programmers in ruby compete in making everything into a DSL; clever programmers in python compete to write the most accessible, readable code. There is a reason there are so many popular frameworks in pyland - people can read them and understand them, rather than using them as black boxes and feeling constrained rather than empowered.

Ello mithic

Hmmm

@@bunchofcells3333 kpop fan spotted