[cpburns2009]

For all of the syntax features Python has been adding over the years, this would be a nice enhancement: making the "else None" optional in the ternary if-expression. E.g.,

    spam = eggs if bar
    # vs
    spam = eggs if bar else None

[genter]

So if "else None" is omitted, if bar is false, then does spam == None or is it unmodified? The former is what I think you want, but that would be very confusing.

[333c]

Yeah, it would be confusing. In Ruby, this would leave spam unmodified.

[8n4vidtmkvmk]

That's even more confusing. There's an =, I expect an assignment to happen. Maybe we just leave this one alone.

[333c]

In Ruby, the `if [condition]` modifier at the end of a line is used for more cases than just assignment. For example, `return if s.blank?` and `raise "invalid" if input.length > 100`. In Ruby, this pattern makes it clear that the statement is only executed if the condition is met.

I'm not advocating for this feature to be added to Python, just explaining why it's not confusing in Ruby.

[mypalmike]

Though I used it for 2 years of it as my primary language at work, I never quite got used to Ruby's quirky idioms like this. It just reads badly to me, in terms of quickly understanding code flow, to have statements that start with "raise" or "return" which might not raise or return. Similar to the up-thread comment about assignment.

[trehalose]

Perhaps using a parenthesized assignment expression with the walrus operator would be unambiguous:

(spam := eggs) if bar

I think that seems reasonable? It would act just the same as it already does with an explicit `else None`, if I'm not mistaken. I don't find it beautiful though.

[kstrauser]

I almost never use None as the second value here. From my POV, that would be new syntax for an unlikely situation.

[TwentyPosts]

Do we really need more syntactic sugar? Frankly, I am still confused why Python is going for a separate syntax for if expressions instead of just making its regular ifs into expressions

[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.

[cpfohl]

This is literally just a short tutorial helping people get into the cpython codebase. This feedback is off topic.

Related to your comment, though: Python has had this syntax for a VERY long time.