[albertzeyer]

There is an advantage of having this as syntax, which is a difference in semantics, which you couldn't get if this would just be an expression, namely:

    x = func1() if something else func2()

In this example, only func1() or func2() is being called, but not both.

[gray_-_wolf]

I do not understand why

    x = if something:
          func1()
        else:
          func2()

Would not work. At least that is what I imagine when it is said "make if an expression".

[zahlman]

Other languages do this sort of thing, so certainly it "would work". But it's very much counter to the design and aesthetics of Python.

Python is intended to enforce a strong distinction between statements and expressions (`:=` notwithstanding :/) because it sidesteps a lot of questions that one might otherwise ask about how it's intended to be parsed (including by humans).

Being able to write something like your example makes it harder to figure out where the end is, figure out what happens if there's more than one statement inside an `if` (do we only consider the result of the last expression? What if the last thing isn't an expression?), etc. By the time you get to the end of understanding what's happening inside the block, you can lose the context that the result is being assigned to `x`.

At the other extreme, everything is an expression, and you have Lisp with funky syntax. But Python holds that this syntactic structure is important for understanding the code. I sense that this is part of what "Flat is better than nested" is intended to mean.

[__mharrison__]

This doesn't work because the if statement is a statement. Statements don't evaluate to anything in Python, so you can't assign it to x.

[8n4vidtmkvmk]

Hence "make it an expression"

[otabdeveloper4]

It's way to late to fix the "statement vs expression" bug in Python's design.

We could have done that in the v3 switch, but we decided to spend man-centuries of effort on chasing already deprecated legacy Windows Unicode semantics instead.