On Oct 27, 2019, at 17:27, Chris Angelico
and the fact that throw() isn't in everyone's toolkits already suggests that this really isn't a major problem to be solved.
Searching on “python raise expression”, the first hit is a StackOverflow question where the asker is looking for exactly this functionality, and, while the accepted answer is “just use a statement” (with some nice explanation), another upvoted answers offers (and explains) a throw function named “raiser”. There are lots of other SO hits, and hits elsewhere, and about half of them are for this issue and include some variant of this solution. I didn’t see a single compelling examples where it really seemed justified, but still, people are looking for it, and finding it. (And they’re finding it under a variety of different names, which makes it harder to mass search code to see how often it’s being used…) Grepping my pile of one-off scripts, I haven’t used my throw function in a few years, but I have used it at least a couple dozen times in the past. Many of them are abusing throw(StopIteration) to fake a “takewhile clause” in comprehensions (which was never a good idea, and doesn’t even work anymore since 3.7, but apparently I used to do it…), and all of the rest would be not just more readable, but shorter too, if I broke up the giant expression the throw was in. But I think the OP might prefer my old giant-expression code, even though I think it’s terrible, because the cleaner and shorter version would usually “waste” at least one local variable storing an intermediate. Anyway, I don’t know how much all of this matters. Whether people are using it frequently or not, and whether the vast majority of uses are bad or not, it’s as easy to find it today as it would be if we added it to the docs somewhere or even included it somewhere in the stdlib, and trivial to use once you find it, so i don’t think we need to bend over backward to make it easier.