<div dir="ltr">The raise statement cannot be used as an expression, even though there is no theoretical reason for it not to. I don't see any practical reason either - except the fact that it requires changing the syntax.<div><br></div><div>I have found this idea mentioned by Anthony Lee in a thread from 2014, regarding "or raise", <a href="https://mail.python.org/pipermail/python-ideas/2014-November/029921.html" style="line-height:1.5">https://mail.python.org/pipermail/python-ideas/2014-November/029921.html</a>.<span style="line-height:1.5"> B</span><span style="line-height:1.5">ut</span><span style="line-height:1.5"> there is nothing against the idea there</span><span style="line-height:1.5">.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Yes, it could easily be implemented using a function, but this seems to be an argument against *augmenting* the language, not against *changing* it. Moreover, this function will have uglier name, since `raise` is taken. </span><span style="line-height:1.5">(It could have been the other way around - omitting the statement entirely, leaving only a built in function `raise()`. I'm not suggesting that, of course)</span></div><div><div><span style="line-height:1.5"><br class="inbox-inbox-Apple-interchange-newline">As mentioned there, it does add a single line in the traceback - which is not immediately what you are looking for.</span></div></div><div><br></div><div><span style="line-height:1.5">Python's tendency towards explicit control flow is irrelevant in this case. An exception can already be raised from anywhere, at any time, and there's no way see it from the source code (unlike e.g. break/continue).</span><br></div><div><br></div><div><span style="line-height:1.5">Such a change will (only) break external tools that use the ast module, or tools analyzing Python code that uses this feature. This happens at every language change, so it can be done together with the next such change.</span></div><br>Use cases:<div><br>    result = f(args) or raise Exception(...)<br class="inbox-inbox-Apple-interchange-newline">    result = f(x, y) if x > y else raise Exception(...)  <div><br>    f(lambda x: max(x, 0) or raise Exception(...))<div><br><div>    d = defaultdict(list)</div><div>    ...</div><div>    d[v] or raise KeyError(v)</div><div><br></div><div>    try:</div><div>        return foo()</div><div>    except:</div><div>        return try_bar() or raise</div><div><br></div><div>To be honest, I'm not sure that this change is worthwhile. <span style="line-height:1.5">Admittedly t</span><span style="line-height:1.5">he use cases are weak,</span><span style="line-height:1.5"> and i</span><span style="line-height:1.5">n some ways this is complementary of the (sadly rejected) "except expression". </span><span style="line-height:1.5">I would still like to "finish that thought", so - why not?</span></div><div><br></div><div><div><span style="line-height:1.5">~Elazar</span></div></div></div></div></div></div>