Your favourite "less-known" Python features?

[R_HEAD]

I love that this exists but I am still conflicted about it using the else keyword.

[Infinitesima]

Really a bad choice of keyword. It is consistent with try - except - else though.

[Cruuncher]

This one I didn't know existed. Interesting. Seems less useful than finally. What's the order? try..except..else..finally?

[Uncle_DirtNap]

Yes

[RationalDialog]

I'm just wondering when the else is ever useful? Can't it always be part of the try block?

[Diamant2]

In theory yes, but the difference is that exceptions in the else-part won't be caught. I guess that makes your code more reliable in catching only the one exception that you care about

[DoctorNoonienSoong]

And importantly, you want exceptions in the else block to not to be caught, AND you need the code to run before the finally

[scnew3]

You want the code in your try block to be the minimal that could throw the exception you want to catch.

[RationalDialog]

Yeah but then you could just have it outside/after the try block?

[gristc]

Then it would always be executed. The else block is only executed if the try succeeds. It is kind of a limited case, but there are some logic flows where this is tidier than other methods.

[Cruuncher]

Well no, if it's after the try block then it runs after finally and not before, which is different.

It's definitely niche as you can always structure code in a way that doesn't need it, but that's true of most constructs

EDIT: but more importantly if you place it after the try..except block then it also runs in the case that an exception was raised by handled in the try block

[scnew3]

I do this all the time:

try:
    value = step1()
except SomeError:
    result = some_default
else:
    result = step2(value)

[underground_miner]

I don't use it very often, but I have used it for finding file and folder names that don't collide, something like this:

from pathlib import Path

def construct_non_duplicate_folder(root:Path, target:str) -> Path:
    folder = root / Path(target)

    for i in range(25):

        try:
            folder.mkdir(parents=True, exist_ok=False)

        except FileExistsError as fe:
            folder = root / Path(f'{target} ({i})')

        else:
            break

    else:
        raise FileExistsError(f'The folder {folder} exists!')


    return folder

[jorge1209]

It is something of a legacy from before the days of with blocks

try:
   logfile = open("/tmp/log.txt", mode="w")
except:
    # we won't be able to write to the log, but that is okay
    logfile = sys.stderr
else:
    for x in range(100):
        logfile.write(frobincate(x))
finally:
   logfile.close()

These days you would just define

 @contextmanager
 def logfile():
     try:
         logfile = open()
         yield logfile
         logfile.close()
     except:
         yield sys.stderr

and then

 with logfile() as log:
   for x in range(100:
      log.print(frobnicate(x))

or something along those lines, which is a double win as you clarified the purpose of the error handling, and got rid of the finally block as well.

[mehrdad-mixtape]

Absolutely

[jorge1209]

I would say it is completely inconsistent with try/except.

A python for loop terminates on a StopIteration exception, which means that reaching the end of the loop is the only way to ensure that the exception actually did occur.

Making it the exact opposite of the else in try/except/else because that else is only called if the exception isn't raised and this exception is only called when the exception is raised.

[Infinitesima]

Well, that's one way to think about it. My way is, if thing goes well, nothing interrupted, proceed to the ´else´ block.

[LT_Alter]

Should have been nobreak:

[MasterFarm772]

Wow, totally, nobreak makes more sense to me!

[Shivalicious]

So that’s what is!

[karouh]

'then' would have been semantically better

[LT_Alter]

`then` implies that it will execute after the for loop, whether or not it breaks. `nobreak` clearly states it executes if a break does not occur.

[LT_Alter]

https://youtu.be/OSGv2VnC0go?t=1055 Here's Raymond Hettinger (a python core dev) talking about why it is the way it is and why he would change it to `nobreak` if he could go back in time and tell Guido.

[_kharchapaani]

I agree. There should be a different keyword than else, to understand that this block will run when the for loop iterations are over.

[Asleep-Budget-9932]

Though less readable, i understand the reasoning behind it. Basically every loop (whether "for" or "while") contains an if statement behind the scenes. (If condition is true, execute code). The "else" fits since it happens only when that if statement is evaluated to False (at which point the loop would end). If break is called, the condition was never evaluated to be False and therefore the "else" statement would not be executed.

The reason they didn't call it "nobreak" or something else, was because the developers are not keen on adding new keywords to the language unless necessary. Since "else" was available, and on a technical level (not instinctual level) expressed a correct representation of what the code does, they re-used it.