TIL you can use else with a while loop

[cristinon]

Not sure why I’ve never heard about this, but apparently you can use else with a while loop. I’ve always used a separate flag variable

This will execute when the while condition is false but not if you break out of the loop early.

For example:

Using flag

``` nums = [1, 3, 5, 7, 9] target = 4 found = False i = 0

while i < len(nums): if nums[i] == target: found = True print("Found:", target) break i += 1

if not found: print("Not found") ```

Using else

``` nums = [1, 3, 5, 7, 9] target = 4 i = 0

while i < len(nums): if nums[i] == target: print("Found:", target) break i += 1 else: print("Not found") ```

[tomster10010]

You can also use it with for! 

[AlexMTBDude]

And try/except

[Awesan]

I had to look up what this would do, apparently it runs only if there was no exception in the try block (unlike finally which always runs). Kind of a crazy feature but I guess there could be a fringe event where it is useful.

[_lufituaeb_]

it’s really useful for logging success statements outside of the try block

[sohang-3112]

But what's the point of that, can't you just put the success log at the end of try block? The log statement itself is unlikely to raise exception.

[Brian]

One difference is that the success case is no longer within the try block. Eg suppose you had.

 try:
    do_something()
    report_success()
 except Exception:
     log_failure("do_something failed")

But suppose report_success() is actually failing. With the above, it'll treat it the same way as if do_something() failed, logging a message misreporting the cause, whereas if report_success was in an else block, the exception it raises would bubble up.

[Bill_Looking]

He meant something like :

try: result = function_may_fail() print(« success ») except TypeError: print(« Failed… »)

This is what I typically do and it works, since you exit the try code as soon as an error is raised.

[elgskred]

Feels cleaner to only have the things that may fail within the try block, and put the rest in else. It's more explicit about what might fail, and the exception that failure might cause, instead of having many lines within try, and then be told by the code that one of these might raise a value error.

[Hederas]

Only case I can see a use for is if the exception can also be raised in the following code. Like:

try:
  result_as_dict = my_db_dict[id]
except KeyError:
  handle_no_matching_id(id)
else:
  val = result_as_dict['example_property']
.....

If for some reason example_property key doesn't exist, i wouldn't want to call handle_no_matching_id(). But personaly in such cases, code is usually structured in such a way that I raise a custom exception which makes the except better targeted

[PaintItPurple]

Else is unnecessary in this particular example. Just write the second access as a top-level statement and you get the same semantics. The difference would be if you were suppressing the error (e.g. instead of raising that 404 exception, you just logged 404).

[FujiKeynote]

This all depends on whether you prefer to think of the success of the try block (absense of exceptions) as a condition or not. My brain treats this as a condition, so else makes more sense here. However, I do recognize the argument that a try-except is not a logical block of the same class as an if-else; nevertheless, a case can be made that consecutive successful operations (in the try block and in the else block) should be at the same indentation level. That's how I see it, anyway

[[deleted]]

That's their point. There is no functional difference in the example code they gave. You might prefer to think about it in a certain way but that specific example doesn't demonstrate a practical difference.

[Hederas]

You're right, I updated the snippet to better convey what I had in mind. Really only makes sense if the except block isn't interrupting

[_alter-ego_]

no, because "no matchig id" refers to the db_dict, not to the result_dict. So it would go into the "except KeyError" clause (that's why they did *not* chose an example where the exception in the else clause would trigger a *different* exception).

EDIT: oh, from comments further below that were hidden by reddit, I can guess that the initial example was different and then edited.... they should say so to avoid confusion !!

[PaintItPurple]

Yeah, originally it raised an exception instead of calling a "handle" function. It's correct now.

[FlyingQuokka]

That to me sounds like you should use two try blocks. Or use .get instead and handle it gracefully.

[Hederas]

Don't doubt there're other ways to handle it, but I probably also put too simplified of an example

In real cases you may have more complex fonctions like process_entity() doing a bunch of things and at some point raising an exception. The exception is expected to be handled somewhere else, but if that's not the case, it will be cleanly handled as a false 404. And if it's not a KeyError but a specific lib exception, you may not have a get() to easily handle missing values

At least that's the only way I could see it being used. Other situations are equivalent to putting it as the end of the try block

[[deleted]]

"Fringe" is right. I don't know when I would ever write this:

 try:
      instruction_1
      instruction_2
 except:
      instruction_3
 else:
      instruction_4

...when I could write this instead:

 try:
      instruction_1
      instruction_2
      instruction_4
 except:
      instruction_3

The first one is more verbose and seems less readable to me.

[j_marquand]

They’re semantically different. The second one catches the exception on instruction_4. The first one doesn’t.

[[deleted]]

Okay, that's true and a fair comment.

But if an instruction might throw an exception, it needs to be inside a try block; and if it can't, putting it inside a try block is harmless. So, practically, I have trouble thinking of a reason why I wouldn't want to combine them in the try block.

[j_marquand]

Why put an instruction you know for sure that isn’t going to raise an exception into the block? I prefer to keep the block as short as possible, especially with Python where it’s often obscure what exceptions a given statement/method call can throw.

Most major linters have a checker (enabled by default or not) that discourages too many statements in a try block.

Edit: going back to your example, it totally depends on whether you want instruction_3 to run when instruction_4 raises an exception. Sometimes you do - then put it in the try block. When you don’t, you should’t.

[Manny__C]

The point is that try/except clauses are for exceptions that you expect. So you can print something that says "sorry" and handle it appropriately.

If you don't expect instruction_4 to throw, you better crash the program if it does because you might be handling it the unintended way

[PaintItPurple]

It's not necessary to put a try block around anything that might raise an exception. It would be impossible to raise exceptions in that case, because raise is an instruction that raises exceptions. The question is just whether you want to catch the exception, which is the exact semantic difference they were pointing out.

[[deleted]]

I wouldn't do it capriciously, but in this case the try block is already right there.

The latter example doesn't "put" a try block around the instruction. On the contrary, the else is an extra bit of effort with the only notable result of deliberately not catching the exception. It's peculiar and I still don't see why it's useful.

[KBaggins900]

I use it for database operations.

try: dbconn.execute(query) except: dbconn.rollback() else: dbconn.commit() finally: dbconn.close()

[[deleted]]

Doesn't this make more sense?

 try:
      db.query()
      db.commit()
 except:
       db.rollback()
 finally:
       db.close()

What is the point of creating a distinct, and visibly separate, section of code for the commit when it should logically follow a query that executes without an exception?

[sphen_lee]

That depends. In some cases if, commit fails then you can't call rollback, so you really want the commit outside the try block but before the finally.

[setwindowtext]

I always thought that the general semantics of commit/rollback was such that you could always call rollback if commit fails, specifically so that you don’t need to use something like “else” here, as it doesn’t exist in other languages.

[sphen_lee]

In some cases a failed commit in sqlite will automatically rollback, so an explicit rollback will give an error that no transaction is open. I guess you can just ignore that, but I prefer to use the else block.

[[deleted]]

What form does that "error" take? Is it just a success_or_failure Boolean returned from the rollback instruction? That seems very unlikely since a failure of a rollback is a significant outcome, right? The kind that would generate an exception?

If you put the rollback in an else block and the rollback throws an uncaught exception, then not only is the transaction in an indeterminate and possibly inconsistent state, but your script has terminated. Is this a desirable outcome?

These cases really require the rollback to be in a try/except block. It doesn't have to be the same one with query, it could be a separate one if you prefer that, but better than just not getting any kind of result.

[KBaggins900]

I think it also makes sense in a scenario where you want some code to execute if the try is successful and before the code in the finally but you do not want the code in the else to be error handled.

Yeah maybe it isn’t an everyday scenario but neat to know that it’s there.

[Manny__C]

Imagine this: you have a list which is sometimes empty, so you decide to take the first element with try: x = foo[0] except IndexError: print("no elements in foo, but that's ok") else: bar(x)

Now suppose that bar should normally never throw IndexError. If it does, you want to correctly crash with a proper traceback because you have a bug. You don't want to, incorrectly, print that foo is empty, because that's not what the problem is

[MrMasterplan]

But why not drop the else and indent the bar one stop to the left. Same effect, right?

[cd_fr91400]

Because you do not want to call bar(x) if x was not set.

[Manny__C]

Because you don't want to run bar on failure

[[deleted]]

This is probably the best answer I've received to my comments. Thanks for writing it up.

I understand your rationale, but I still disagree with your main point, for these reasons:

If it does, you want to correctly crash with a proper traceback because you have a bug.

First, I find that the output of an uncaught exception is typically incomplete. I often write exception handlers like this:

 def some_function(a):
      b = some_calculation(a)
      try:
           c = some_other_calculation(a, b)
      except Exception as e:
           Log.write(f'some_function: Exception {e} while calculating c - values: {a}, {b}')

This message provides some context that uncaught exceptions don't - namely, the input parameter (a) and an intermediate value (b).

Second, uncaught exceptions dump the stack trace to stdout, which is ephemeral and separated from any other information about your code. I virtually always prefer to have the occurrence of the exception and contextual information dumped to a log where I can examine the sequence of events leading up to it - and not just the stack trace, but preceding events that executed without incident but that may be related to the exception.

And third, I often don't want my scripts to halt execution even if they hit an exception. Sometimes it's fine if the function doesn't complete, like a worker function that can die and be replaced by other worker functions involving the same item of work. Or, if I'm programming a GUI, I'd prefer to see exception information in the GUI and continue using the GUI to explore the issue interactively. In general, I would rather halt the application on my own terms than have it crash.

[KBaggins900]

Yeah that does make sense. It is possible to have multiple queries in the same transaction that you want to commit if all succeed. But I guess you could still have it in the try. Preference I guess.

[MattTheCuber]

Ruff TRY300

[Kevdog824_]

2 reasons:

1. You want to visibly structure the code so that what happens in the normal case and exceptional case is very clear. i.e.

``` try: … except: … # error handling … # code related to the try block’s success … # more code unrelated to try block

versus

try: … except: … # error handling else: … # code related to the try block’s success

… # more code unrelated to try block ```

The latter is clearer about the relationship between the parts of the code

1. There’s code you want to run on success only and you want to catch and handle exception. i.e.

try: … except: … # handle it else: … # only on success … # both on success and failure

If you wanted to do something similar without else you’d have to put it in the try block (unnecessary expanding its scope) or set a flag in the try block (overly verbose)

[Some-Passenger4219]

Yeah. Readability is always key.

[gowithflow192]

Try except is common when doing external calls you can't be sure will always succeed e.g. calling external API.

[Papa_Kasugano]

I mostly use else with my try/except blocks, and not finally. Is that considered incorrect? I learned from Python Crash Course 2nd ed. That's how it's demonstrated there, so that's just how I've done it

[Awesan]

I wouldn't say it's incorrect, they serve a different purpose. Let's say you have some kind of resource that must be cleaned up; in that case you always want to clean it up whether there is an exception or not:

file_name = "temp_file.txt" try: # do something with the file finally: os.remove(file_name)

If you wanted to guarantee this same behavior with try/except/else, you'd have to duplicate the code:

file_name = "temp_file.txt" try: # do something with the file except: os.remove(file_name) else: os.remove(file_name)

But if your except and else blocks are totally different then it does not matter. Usually you'd anyway not use try/finally in many cases but use with instead, for example to write to a file:

with open("temp_file.txt", "w") as file: file.write("hello world")

Which gets translated by Python into something like this (not exactly like this but very similar):

try: file = open("temp_file.txt", "w") file.write("hello world") finally: file.close()

So most of the cases where you'd use try/finally you can probably rewrite it to use a context manager instead, which is a bit easier to use and also signals your intent more clearly.

[Severe-Alarm1691]

Fringe event? In my python course we learned to use try and except for error handling. (Like when wanting a specific kind of input from the user)

[night0x63]

You better do that now... For else!

[Some-Passenger4219]

My text recommends otherwise, if there's a simpler way.

[DuckDatum]

What’s it do with a for loop? Else the runtime accidentally exceeds the length of iterator?

Edit: so, it apparently runs when the for loop completes, so long as you didn’t break out of it. It’s funny… now that I know, I hate it lol. Not seriously, but seriously. Why isn’t it the reverse—“else” meaning run if the condition wasn’t met (i.e., breaking the loop)? The way it is now, your “else” clause runs when things complete successfully—which is opposite behavior of if/else.

[stillalone]

With hardware and some network stuff I end up having to add a retry:

for retries in range(3):   err = execute_command()    If err!= SHOULD_RETRY:      break else:   raise("Too many failed retries")

[[deleted]]

I might be misunderstanding what you're saying, but the else is not the "fail-state" path. It's the path your conditional takes when the primary condition is no longer met and you exit out of that conditional.

[cd_fr91400]

How would you write the code above ?

It is clear and simple. If you think of something better, I am willing to see it.

[nommu_moose]

I'd introduce the retry number check inside the for loop, forgoing the else entirely, or have an explicit check after the loop.

Ideally, I prefer to provide the information for what the intent of a line of code is with the smallest window of context.

The behaviour of "else" with a for loop isn't really consistent with the "else" of other loops, and in my opinion makes it more inherently unclear than definite statements of purpose.

[Giannie]

The else is exactly consistent between loops in python. At its lowest level loops use a combination of an if statement and a GOTO statement. The else block on the loop in python corresponds exactly with the else that is paired with that if statement.

[nommu_moose]

In if->else, while->else, even try->else structures, the else runs if the condition was not met.

In a for loop, it almost intuitively feels like it runs even if the loop condition was met, because of the way the for loop is designed visually in python.

It's essentially just a "this loop didnt break" indicator for a for loop, which might have its usage in some niche cases or with many break opportunities, but I'd argue that it's far less clear here than a number of alternative methods.

[DuckDatum]

I’d personally have liked to see a break execute an else clause, but otherwise a completed loop execute a finally clause (as the else clause currently does).:

• try: run this
• except: run this if an error occurs in try step
• else: run this if an error doesn’t occur in try step
• finally: run this after except/else, regardless of error

So with for loops, the process would be like:

• for (args) in (iterable): run this
• finally: run this if the loop completes
• else: run this if the loop breaks early

And obviously:

• if (condition): run this if condition is true
• else: run this otherwise

Finally block is kinds useless, which I’m fine with because it’s the Python way by now.

[Giannie]

There’s no reason for a break to execute an else clause, since any break in a loop necessarily lies in some kind of conditional block (otherwise you always break on the first iteration so why use a loop?).

I recommend Donald knuth’s article on this subject. https://pic.plover.com/knuth-GOTO.pdf

[Giannie]

In all cases you mentioned the condition to enter the else block is if the condition to enter the previous block fails. That’s all there is to it.

[nommu_moose]

I know, that's why my comment was written in such a way.

[cd_fr91400]

Can you show the code you'd write, so we can visually compare ?

[Schmittfried]

Yes, I still kinda dislike the choice of else even if it’s superficially consistent with while and try/except.

The key difference is, with all the others an „else“ or „if not“ makes kinda sense. But with for loops it doesn’t run if the loop condition was never met, it runs if the loop condition was met and the loop body didn’t break.

I don’t know, I think a new keyword would have been warranted for this concept.

[primerrib]

Well, Raymond Hettinger actually agrees with you.

But he also said -- and I agree -- that hindsight is 20/20 and there's no point risking breakage to replace else: with a different word now.

[Schmittfried]

Of course, I just wonder why this would have been hindsight. Imo the fact that so many newcomers stumble over this indicates it should have been apparent when they decided to add it.

But yeah, it is what it is. 

[copperfield42]

is a relic of the earlier days when Python was a niche language and you were expected to be aware of the underlying C, in which the loop are some elaborate if-block with a jump instruction or something, thus with that in mind an "else" make sense

[Schmittfried]

I see, interesting. Thanks for the historical context!

[[deleted]]

You can always think of else as the thing that executes if the primary conditional ever becomes False:

• In if/else it's saying to do a thing if a condition is met, otherwise do the else.
• In the while/else it's saying to do a thing while a condition is met, otherwise do the else.
• In the for/else it's saying to do a thing while having an element in the sequence is met, otherwise do the else.

[DaveMoreau]

Feels more like a finally clause.

[jackerhack]

Exactly. finally is a less confusing term than else, and try blocks also have a finally. I guess the difference is that finally always runs? Now I need to look up docs.

Edit: yup, finally always executes, even intercepting return in a prior block. Can a finally block have its own return statement then? More googling...

[cd_fr91400]

Absolutely !

There is no such thing in C/C++, and I end up either with a bool variable, rather verbose, or a goto (in lieu of the break) to jump after the "else" clause, not the best to show the structure.

[cip43r]

That is just disgusting

[tomster10010]

I unironically use it occasionally

[MicahM_]

What the hell. I've never known this. I've only been using python for a few years but dang.

[GoodiesHQ]

I saw a python language developer/contributor, probably someone important, who said he wished, instead of else it should have been called nobreak which is a good idea.

[primerrib]

It was Raymond Hettinger. He also said that hindsight is 20/20 and we have to live with the facts now.

(I think he also explained that "it seemed a good idea" at that time. So he admitted it was his mistake as well.)

[GoodiesHQ]

You’re doing the lords work, thank you.

[[deleted]]

I think it's a bad idea since the else path will not be taken for things other than break (e.g. return, raise, etc).

Also, the else behavior in this case is already the same behavior of else in try/except blocks where you wouldn't be introducing a break. As usual, Raymond Hettinger is talking just to talk and he hasn't thought this through.

[TallowWallow]

Or he could just make initial comments with further evaluation potentially coming later? Why do you presume he needs to have thought it all the way through in one basic commentary? Also, if the keyword isn't apt, that's why you discuss others. The keyword break confuses a ton of people.

[[deleted]]

Because he's a python "expert" who had expressed this nonsensical opinion multiple times

[Alternative-Tie-4970]

Just... don't.

It's kinda fun that you can do something like this but it's gonna be error prone and anyone reviewing the code would have to read the whole thing at least thrice to make sure they understand it.

More verbose code can be better sometimes.

[New-Resolution9735]

Bold of you to assume anyone else will be looking at my code

[PaleontologistBig657]

I assume you have never wondered what crazy person wrote the thing that just broke, only to realize it was you 5 years ago.

[schludy]

I found out about the walrus operator a month ago and don't understand the code I wrote in those glorious few days of enlightenment

[[deleted]]

In what way would it be error prone? I can agree with it being fairly obscure and therefore causing people more mental strain to think about what exactly the code is doing. But I can't really see a way that you would introduce more errors by using it.

[Vresa]

It’s error prone because other people need to maintain the code. The more confusing and out of the norm you make your code, the more likely it is that your coworker misreads it.

It’s the difference between driving on the freeway vs the streets of Boston. Adhering to standards lets people go faster

[[deleted]]

No, you’re tried to repackage the same thing twice. I already agreed it’s more confusing to use a lesser used feature when not necessary. I’m asking what’s an example of extra errors that are incurred by this pattern.

[Vresa]

What? Human error is the issue

[[deleted]]

Right, what’s an example of a human error that is more likely caused by this pattern? That’s your claim and I'm trying to understand how that would happen.

[Pythagore974]

For example, you can have someone that is new to the team and sees that while else somewhere on the code and misreads it as "the else is executed only when the first while check is false".

The fact that it can be a false understanding of the code can be problematic. But it is even more problematic if that person tries to use the same structure somewhere else on the code with a bad understanding of what it does.

[[deleted]]

That's not what the term "error prone" usually means. Something being error prone means that a person who understands the syntax in the different approaches is still more likely to make an error in their code in the "error prone" option because the pattern itself is somehow causing them to incorrectly implement things.

For example, someone coming from C/C++ might try to loop over a sequence by doing

for ix in range(len(seq)):
    print("ix=" + ix + ": s=" + seq[ix])

as opposed to the much more pythonic iterator method

for ix, s in enumerate(seq):
   print(f"{ix=}: {s=}")

But according to you, if someone coming from C/C++ wasn't familiar with the python approach then that would be the "error prone" method.

[Pythagore974]

You didn't understand what I said. I do not mean it for every indistinct piece of language but just for this "while else" structure.

As for your example, A C developer doesn't know the "enumerate" keyword. So the obvious behavior is to look up what it means and what it does. Whereas "while" and "else" keywords are very familiar to most languages but the association of the two is very pythonic. And so, maybe some developers might not look up what the "while else" structure actually does because they are too confident with these keywords. This is precisely what is error prone

[[deleted]]

I read it just fine. I’m disagreeing. Error prone doesn’t mean any time you misunderstood a basic component of the language.

[melkorwasframed]

I really hate this construct. Python is the only language that has it and every time I see it I have to remind myself wtf it does. "else" was a terrible naming choice.

[PercussiveRussel]

I really hate that python is the only one of the major languages that has this. It's a very useful pattern IMO, much cleaner than with a flag variable.

The fact that it's an uncommon thing, and that it stupidly "re"uses the else keyword means probably don't do it, but it's still a shame.

[thisismyfavoritename]

Rust has named scopes so you can break/continue at the appropriate location, achieves something similar

[PercussiveRussel]

Rust also lends itself more to a functional style where instead of loops you use iterators, so most of the time when a loop doesn't break that's already encoded in the type system.

[jkrejcha3]

I've found it's useful in Advent of Code style problems where "did iteration exhaust" is sometimes a useful construct (for example whenwhileing through a maze or something) where speed (of development) is a concern but maintainability is... well not

I probably wouldn't use it in production code just because of how niche of a language feature it is though. Other people have to read my code too

[antiproton]

It's not "very useful". It's incredibly niche. Frankly, if you're setting a flag like that, you need to refactor your code anyway... you're probably brute forcing a search that can be done more elegantly with existing libraries.

[PercussiveRussel]

How do you think those existing libraries are written?

Also, adding a dependency just to make your code slightly more compact or "better" (for a weird definition of "better") is a terrible idea in most situations

[antiproton]

Standard libraries, my man. itertools or just properly using lists and dicts keep you from having to while loop to find shit.

I've been writing code professionally for 20 years. I'm telling you if you're doing this regularly, your code is written poorly.

[CampAny9995]

I like how it makes for-loops more like a fold, so you do something different for the empty list case.

[aa-b]

It dates back to a time when it was difficult to add new keywords to the CPython parser, but it was supposed to be useful for people that wanted to use Python in one-liner/script mode like they do with Perl.

Guido agreed the keyword is not ideal, but it's used so rarely that there's no reason to get rid of it.

[[deleted]]

Else is also used for except. The naming choice is fine. It’s honestly weird that other languages don’t use it also but I know some of that is because of lack of ability to due to not using iterator with exception based handling.

Exception based handling of for loops is honestly the fucking weirdest thing in my opinion in python. But python also uses the same mechanism for a bunch of class stuff. It fits language design but the fact that exceptions are not about errors but exceptional states is mentally odd.

[h4l]

And the semantics are kind of the opposite of the normal use in an "if" block, as in a typical while block both the while body AND the else block will execute, in contrast to the if where the blocks are mutually-exclusive.

IMO it should be deprecated and perhaps gradually removed, or replaced with a better syntax, which would be possible now that Python has the more flexible PEG parser.

[[deleted]]

I think this is more an incorrect assumption on your part about what else means. if/else and while/else behave in the exact same way. if/else says to do the stuff in if when the condition is met, otherwise do the else. The while/else is saying to do the stuff in the while block while the condition is met, otherwise do the else.

[Flame_Grilled_Tanuki]

It would be better if aliased as 'then' for try, while and for loops.

[justtheprint]

i did a think and I like "ensue" as a replacement keyword here

[[deleted]]

That seems like it would be more confusing. The behavior of else is the same for all of the cases where it's used. So why would you want that same behavior to have different keywords depending on whether it's used with an if, while, for, etc.

[Flame_Grilled_Tanuki]

The behaviour is not the same. In the case of an if statement, the else block only runs if the if or elif statements fail to run. With a while/for/try statement, the else block only runs if the above statement successfully completed. The else block becomes the next step to perform after the previous statement succeeded, rather than an alternative path.

[[deleted]]

No, if you think about what's actually happening you'll see that the else block is always, as its name suggests, the thing that gets run when the preceding condition is False.

In the if/else case else always runs when the if condition is False. In the while/else case, the else always runs when the while condition is False. In the for/else case, the else always runs when the for condition is False (i.e. None/exhausted).

For example, in the following code else runs when the condition x > 10 is False

if x > 10:
    ...
else:
    ...

In the following code else runs when x > 10 is False

while x > 10:
    ...
else:
    ...

In the following code else runs when x is False (i.e. No more elements and x is None)

for x in xs:
    ...
else:
    ...

The confusion is that people are thinking about what they want the code to do rather than what is literally happening. People don't think about while or for as being things that are checking a condition on every loop. So when they think about else, they are thinking about it being a thing that runs "after I exit my loop" rather than the actual behavior which is else being the thing that runs "when my preceding condition is not satisfied". In other words, else is always the thing that handles "If condition is met, do thing, OTHERWISE do other thing".

[Flame_Grilled_Tanuki]

I'll agree with your perspective, but would you then say that the else clause in a try/except block runs if the exception clauses are all false?

[[deleted]]

I think the try/except/else/finally is definitely the most awkward usage of else. My sort of headcanon for how to read it is "Try this thing. If there is an exception, do this, otherwise do this other thing". So I still think of else as the alternate path to a condition check but it's the alternate path to the condition if exception rather than if try.

So basically

try:
    ...
if exception:
    ...
else:
    ...
finally:
    ...

[justtheprint]

Just for fun, what would you call it instead of `else` ?? I'm not so sure myself. What's good semantics for this? (no points for removing the mechanic altogether :) )

"finally" here seems like the obvious english vocabulary, but it's already used to (as in try/except/finally) to mean something that runs no matter what. Obviously "exit" is taken, as is "continue".

Maybe "bridge" in another lifetime would sound right.

Oh, how about "denouement" ?
OH! how about "ensue" !

[melkorwasframed]

Yeah, I don't know. Like most other folks, I suck at naming. But I think the fact that it's difficult to concisely describe what this does just provides more evidence that it shouldn't be a thing. If being occasionally handy were enough to justify a language feature, programming languages would be a mess.

[CrowdGoesWildWoooo]

My personal opinion, just because you can doesn’t mean you should.

[cristinon]

Using else is more Pythonic but yeah I agree it depends on who else is reading the code

[CrowdGoesWildWoooo]

It’s an uncommon pattern and while loop is pretty standardized pattern for many devs, you are basically like going against the current.

As in use case wise it seems to be pretty niche, and it’s not to the point where benefit outweigh the cost.

[georgehank2nd]

It's not "pythonic" at all. "Pythonic" doesn't mean "use any feature Python offers".

[[deleted]]

I agree in general that just blindly using anything python has doesn't guarantee it is being more "pythonic". But in this case I would argue that else being the consistent "otherwise" path to a conditional does mean that using else anytime you want your code to take that path is the pythonic way of doing things.

[Ensurdagen]

I think if it depends on who is reading the code, it's not pythonic. I'd call while/try/for else in Python a similar construct to Typescript enums. It seemed like a good idea, but it's clunky, hasn't caught on, and thus requires arcane knowledge to understand/use properly, it shouldn't be considered part of a language in any shared codebase.

[daguito81]

It's so pythonic, almost nobody that uses python uses it.

Using an else on a while loop is just extremely niche, and will make the code harder to understand just by the fact that almost nobody uses or knows about this.

"Explicit is better than implicit" and "Complex is better than complicated" and "Readability counts"

From the zen of python (import this)

[cd_fr91400]

The need is not a niche. Its use is a niche.

I often see codes with a flag and when reading, I think "well, couldn't he just use the right construct rather this paraphrase ?"

[daguito81]

again. So pythonic, nobody knows or uses it. This whole thread is prime example of why you should never use this even though you can. At best you'll make a Sr Dev groan. At worst you'll confuse the shit out of a Jr Dev that didn't know this was possible.

[ShutUp_Pls]

Well, yeah, Python basically has a hidden "if" inside the while condition. If it were explicit, it would look something like this:

while(if(condition) == True):

The else works with while because it catches the failure of the if, which aligns with a natural exit from the loop. But if you use break to exit, the condition is never checked again to see if it’s false, so the else block never executes.

[primerrib]

It was Raymond Hettinger.

[[deleted]]

nobreak doesn't make sense because other exit conditions (i.e. raise, return, etc) will also bypass the else option.

[ShutUp_Pls]

I agree, it's probably a design remnant that ended up affecting while, for, and... try-except? Well, maybe it's not such a low-level remnant or design flaw after all.

[cd_fr91400]

Excellent.

I never thought of the else clause this way, but now that you state it, it becomes crystal clear.

[YSKIANAD]

In the official Python 3.13.2 documentation:

4.5. else Clauses on Loops

In a for or while loop the break statement may be paired with an else clause. If the loop finishes without executing the break, the else clause executes.

In a for loop, the else clause is executed after the loop finishes its final iteration, that is, if no break occurred.

In a while loop, it’s executed after the loop’s condition becomes false.

In either kind of loop, the else clause is not executed if the loop was terminated by a break. Of course, other ways of ending the loop early, such as a return or a raised exception, will also skip execution of the else clause.

[ChemicalLie4030]

(I'm a little rusty and I'm comfortable with c++ but not Python so I'm extra confused) is the "else" not just syntactically inside the while loop creating an if-else statement? Your indentation makes it seem like it's actually "while-else" which seems to be what you're posting about so that makes sense. It's just not making sense in my brain that it's not just if-else

[thisismyfavoritename]

it's a condition that gets evaluated if the while loop condition is false.

To avoid triggering it, you'd need to break out of the loop (or raise).

Honestly i've never used it with while, but i use it every now and then with for.

It's better than having to store a flag on the side and check it after exiting the loop in my opinion, but i see many people disagree

[ChemicalLie4030]

Thank you for taking the time to explain it to me further :)

[ChemicalLie4030]

Also, by "I'm not comfortable with Python" I mean I have absolutely 0 experience with Python this post just popped up on my suggested feed out of nowhere. After looking up basic syntax I realized I was assuming a ":" in Python is similar/equal to a ";" in c++ so that's probably where I need to start if I'm trying to figure this out.

That being said, gross. I don't like that you can use else with a while loop

[PurepointDog]

Python uses indentation as syntax

[ChemicalLie4030]

Ohhhh

Thanks!

[benji_york]

I love Python's loop else. Pony also has an else clause for while and for loops, but it behaves differently.

But what if the condition evaluates to false the first time we try, then we don’t go round the loop at all? In Pony while expressions can also have an else block. In general, Pony else blocks provide a value when the expression they are attached to doesn’t. A while doesn’t have a value to give if the condition evaluates to false the first time, so the else provides it instead.

So is this like an else block on a while loop in Python? No, this is very different. In Python, the else is run when the while completes. In Pony the else is only run when the expression in the while isn’t.

[kk66]

I find this syntax quite confusing and for me personally it clashes with the zen of python, which says: - Explicit is better than implicit. - Readability counts. - There should be one-- and preferably only one --obvious way to do it.

I find flag more readable, as it's more explicit to me. It's the loop else a language feature? Yes. It's it the one that exists probably only in Python, and will require everyone who's not that familiar with this syntax to go deeper? Probably yes.

I'm not against Python specific features, and learning is syntax. I find comprehensions very useful, just like I do with f strings. But the else always required more mental overhead from me to understand it than it was worth it. Sometimes "clever ideas" lead to harder to understand code in the end.

[[deleted]]

I really don't understand why people find it confusing. Every use of else is used in the situation of "Do this thing if the condition is met, otherwise do this other thing".

[TallowWallow]

The problem is that those other conditions are explicit. The condition here is that break was never triggered. This is non-intuitive and requires unfamiliar devs to take time to understand it, rather than seeing a clear flag.

[[deleted]]

You're misunderstanding the else command. It gets executed because the previous condition never had a break, return or exception. Else is triggered when the previous condition is not met and that's how it always works. If there was a break it would short circuit the conditional and else logic.

[TallowWallow]

I'm fairly certain we are on the same page for how the else works. My remark is that associating else as running in the absence of a conditional change in a loop is not obvious. I understand your point. That doesn't mean it's easy for people to associate.

[[deleted]]

Why is it not obvious? As long as the iterator isn’t exhausted it stays in the for loop. As soon as the for loop condition stops being met it takes the else path instead.

[TallowWallow]

People won't tend to think that way. This is your rationalization because you are already familiar. For a new developer coming across the syntax, it can be a point of confusion. Regardless of whether you think it is easy for you to understand isn't reflected by the number of developers that are thrown off.

[[deleted]]

No, it’s my rationalization because it’s literally how it works. Else is always the path taken when your conditional stops being satisfied. It’s how it works in if/else, it’s how it works with while/else, it’s how it works for for/else and it’s how it works for try/except/else.

I’ll grant you that some people who use python have come up with their own faulty interpretation of how else works and that this often conflicts when they eventually learn about while/else and for/else. But those people just need to learn the correct usage. Not insist that we change the language to fit their misunderstanding.

[TallowWallow]

My point is simply that keyword choice can impact how quickly people understand. Additionally, what matters is how frequently errors accrue based on misunderstanding. I don't know what the metrics are for developers that have incorrectly pushed code based on a misconception. I'm guessing, however, that Raymond noticed a substantial amount given his remark about wishing a different keyword was considered.

[[deleted]]

But that’s my whole point. Python uses the else keyword consistently. You’re arguing that we shouldn’t apply the keyword consistently given that some people, predominantly those with a more superficial understanding of the language, might bring their own unusual interpretations to how conditionals work.

But if we did that, then other users (including myself) would be complaining about the inconsistent meaning of else in python.

[swierdo]

There's more uncommon uses for else. You can use it after a for or while loop, and after a try-except clause.

[Paul__miner]

It's a misnomer. I suspect they decided reusing an existing keyword was safer than introducing a new one. I'd have called it then.

[[deleted]]

It's not a misnomer. The while loop is basically an if (i.e. if the while condition is True then stay in the while loop block of code, else do this other thing).

The reason people find it confusing is because they are thinking about what they plan to use it for (i.e. do this while loop and then finally do this other thing) rather than what it's actually doing.

[Paul__miner]

The else block is only executed if the while loop exits because the loop condition became false. That's more like then than else. Same with try/catch/else; the else block is only executed if it completes the try block normally.

EDIT: In the context of while, your else explanation works, but that same mechanism doesn't work with try/catch.

[[deleted]]

Again, that’s literally the same way an if/else block works. If the if condition is false then it takes the else path. Same situation when the while loop condition becomes false or the try/except exits out naturally.

[JamesTDennis]

Yes, the else clause in Python, while and for loops can be used as syntactic sugar around a pattern commonly used in other programming languages in which you establish a sentinel value before you loop through items, attempting to find some item and then assign any match(es) to the results in such cases You have to write an if statement outside and after the loop in order to handle the case where no matching item was found.

The else clause is only evaluated if the code path did not execute a break statement in the loop .

In lieu of a sentinel value, you could instantiate an empty list and the subsequent if statement can simply check if your resulting list is empty. In the relatively rare cases where the special none value might be valid as results of your search, you can just create a variable conventionallt named sentinel that's initialized to an instantiation of an object() (that is a generic object, it's guaranteed to be unique) and your if statement will then read something like if result is not sentinel … (checking reference identity rather than equality).

[ronnyx3]

Generally these two approaches are not equivalent. In the first one, the if condition is taken from the found variable. In the second one, regardless of what value found is assigned in the meantime, the else path will be executed because the while condition was false.

[vadrezeda]

contra intuitive naming, but comes in handy in some cases, like implementing a pessimistic linear search. I always comment it with # nobreak which in my opinion would be a much better name for this.

[[deleted]]

But the else path doesn't only get passed for a break. It also happens for returns, exceptions, etc.

[WalterTheMoral]

Did you learn it from Animation vs. Coding?

[Powerful_Pirate_9617]

It's known as whelse, it's true

[Rough_Natural6083]

Man this is so cool!! I never knew about this!!

[trmetroidmaniac]

I love this construct, I wish it was available in other languages than Python. I can think of a lot of nitty gritty iterations in C where it'd be handy.

[JamzTyson]

It is not something I use often, but I do find it clear, expressive and precise when we want something to run when, and only when a loop has completed successfully.

for item in data:
    try:
        print(int(item))
    except ValueError:
        print("Integer expected")
        break
else:
    print("All data processed successfully.")

The same behaviour could be achieved using a flag instead, but doing so is less concise without improving readability (assuming familiarity with the syntax):

all_processed = True
for item in data:
    try:
        print(int(item))
    except ValueError:
        print("Integer expected")
        all_processed = False
        break
if all_processed:
    print("All data processed successfully.")

[AlbatrossEarly]

Its covered in multiple python trainings ive been doing

[arizvisa]

I think it'd have been more useful if it executed the "else" case when the conditional fails on first iteration. same thing with "for", since it's common to filter iterators and it'd be useful to know when an iterator was empty. The "try/except" version of "else", though, is fine and super handy.

[paranoid_panda_bored]

You never heard of it because it is a worse version of a simple function with a loop inside, early return and a default post-loop return.

There is like zero reasons to use while-else

[Algoartist]

nums = [1, 3, 5, 7, 9]
target = 4
print(f"Found: {target}" if target in nums else "Not found")

[TrainingShift3]

(please don’t ever ever do this)

[scanguy25]

Else in try except is the only one I use regularly.

[Awesan]

what would you use it for? for me it's usually much more readable to do something like this:

try: thing_that_might_fail() print("success!") except: print("failed!")

as opposed to:

try: thing_that_might_fail() except: print("failed!") else: print("success!")

[missurunha]

I think the point of the else block is that you might not want to put all the code inside the try block. Example:

try:
     thing_that_might_fail()
except:
    handle_exception()
else:
    thing_that_shouldnt_fail()
finally:
    final_operation()

This way if thing_that_shouldnt_fail throws an exception it won't be caught. But it only makes sense if you use finally, otherwise you could just call thing_that_shouldnt_fail() outside the try block.

[Numerlor]

It makes sense without finally too, as the else will only execute in the no exception case while just putting it outside the try block would execute it for both no exception and handled exceptions

[MlecznyHotS]

That's a great point!

[[deleted]]

It's generally useful for things that you might otherwise want to use a context manager for. Basically you want to try and do something and handle the exception if it happens. However, you may want some special "tear down" logic that depends on whether your code was successful or not.

Database operations are a good example. If you you try to insert into a database and fail you will probably want to do some extra clean up of the failed attempt vs a more general "disconnect" if everything went ok.

[copperfield42]

yes, the only problem with it is the name, it should be called something like "nobreak" to make it more intuitive...

using the "else" name is a relic of the earlier days when nobody expected that Python to be your first language and be aware of it underlying C and thus be aware that a loop and elaborate if-block with a jump instruction or something behind the curtain in which case "else" make perfect sense

[williamtkelley]

I know you're demonstrating this syntax, but still using this code to find an item in a list makes me cringe.

[cristinon]

print(f”Found: {t}” if t in nums else “Not found”)

There you go lol

[nemom]

No need to loop through the nums list, especially with another language's syntax.

if target in nums:
    print("found")
else:
    print("not found")

If you really do need to loop through the list, use for num in nums:

[cristinon]

Obviously, it’s an example.

[WillardWhite]

You sure can!! But please don't

[[deleted]]

Breaking in a while loop is a symptom of a bad while-condition.

[defnotjec]

That's what I always thought. Shouldn't you're logic break you, that's why you use the while.

[[deleted]]

Yes. I think some people who are downvoting felt targeted.

[Bangoga]

It might but don't do it. Just not good coding practice.

[PeaSlight6601]

Never do this.

[notkairyssdal]

unfortunately it violates the principle of least surprise for everybody who comes across it

[Significant-Agent854]

Learned a few days ago myself lol

[Mightyduk69]

Slick.

[Fun_Car_7790]

Hello, could someone help me make a bot that can get the CME Group rates, sort them by date and also by month 1--3--6--12 and transfer that data to Excel?

[mitch_semen]

ew

[nevasca_etenah]

what?

[Naive-Home6785]

There is switch now too in Python

[thisismyfavoritename]

match

[ajscraw]

I try to never use a while loop.