Dom Grigonis writes:
I came to this, because people seem to want one-liners for certain things and what I came up with is that maybe more concise if-else expression could help.
But "encourages one-liners" is generally considered an anti-pattern in Python. Let's see why,
# Fairly reasonable case.
def foo(a: bool, c: float, d: float) val = a ? (c ? c : d) : (d ? d : c) return val
What's not so great here? 1. The argument names are not going to be single characters, unless you intentionally name that way for the sake of one-line-ism. That severely detracts from your claim of readability. The one-liner is arguably[1] more readable than the Python version, but you've definitely made the whole function less readable. 2. Comparing floats, even against zero, is a bad idea. So I would wrap them in math.isclose: val = a ? (not isclose(c, 0) ? c : d) : (not isclose(d, 0) ? d : c) Pretty long, not that easy to read. Of course if you had intelligible variable names it would be worse. The point is *not* to give you a hard time about comparing floats for equality, we've all done that. It's that in even in this example, done safely you have more complex expressions than just variable references. In general you will have function calls adding parentheses -- and thus confusion. Perhaps there will be lists or tuples involved. You can precompute them and assign them to short name variables, but then you lose the one-liner-ness. 3. OK, how about ints then? Yes, that would work, but how frequently are you going to be comparing against 0? Here's a more realistic case, with readable short argument names: def clamp_int(n: int, lo: int, hi: int): # I wouldn't elide this test because if lo > hi you get a # plausible but necessarily erroneous value if lo > hi: raise ValueError(f'lo = {lo} > {hi} = hi') val = n < lo ? lo : (n > hi ? hi : n) return val Agreed, the expression using Python's syntax would be worse, but I think this is much more readable: def clamp_int(n: int, lo: int, hi: int): if lo > hi: raise ValueError(f'lo = {lo} > {hi} = hi') if n < lo: val = lo elif n > hi: val = hi else: val = n return val and it would be more readable yet if you got rid of the assignments and just returned the value as soon as you see it: def clamp_int(n: int, lo: int, hi: int): if lo > hi: raise ValueError(f'lo = {lo} > {hi} = hi') # Hi, David! Default first!! if lo <= n <= hi: # Yes, Virginia, valid Python! return n elif n > hi: return hi else: return lo (Yes, I know that some folks argue that suites should have one entry point and one exit point, but I don't think it's a problem here because of the extreme symmetry and simplicity of the conditional. IMHO YMMV of course)
I dare you to do a 1-liner with current if-else.
I do use ternary expressions occasionally, but almost never nested. Writing one-liners is never a goal for me, in part because my old eyes can't take in more than 35-40 characters in a gulp.
So maybe, just maybe, making already existing expression more readable can also be a valid suggestion?
We *won't do that*, because of backward compatibility. The syntax of an exist expression cannot change without invalidating a lot of existing code. That's one reason why the bar to new syntax is so high, and it took so long to get the ternary expression: you really want to get it right. That's why Python (like C!) prefers to add to the stdlib rather than the language. Now, you can add a new one that does the same thing, and that's been done. IIRC it took a while to get +=, and C-like ++/-- increment operators have been requested over and over again. AFAIK the async syntaxes do nothing that can't be done with generators, but they make it a lot easier to do it right in the most common cases.
As I said, in my opinion it would solve many existing queries and requests, just because certain things would become very pleasant and obvious how to do in simple one-liners.
One-liners are almost by definition less readable. Even in math papers we break equations into a series of definitions and then build up the final equation from there. As M. Spivak put it in *Calculus on Manifolds*, Stokes' theorem shares three important attributes with many fully evolved major theorems: 1. It is trivial. 2. It is trivial because the terms appearing in it have been properly defined. 3. It has significant consequences. When I have the time and knowledge, I aspire to programming that way. :-) YMMV
Simpler and more logically convenient if-else combined with other elegant python expressions would potentially fill that gap.
I guess. It's certainly true that Python pre-walrus operator had no good solution to the "loop and a half" problem. But I've been programming long enough it's hard to get myself to use the walrus operator in the "assign and return" fashion that C's assignment operator so frequently is.
From where I currently stand it just seems fairly happy middle solution between: very concise narrow functionality requests and very verbose ways of how they need to be done at the moment.
But the functionality you request is extremely narrow in a different sense. At least the way people who develop Python (and GNU Mailman, where I program Python in anger, as they say) taught me, very frequently the most concise expression is not the most readable, and "readability counts". So as above I would likely exand these expressions into statement syntax in many cases anyway, despite having a more concise syntax.
I fully appreciate how likely what I am proposing is going to be even considered. But I really think it should be.
I think you will find almost noone in Python development who would agree that it *should* be. Even if you 100% discount the "20 years late" objection that stops it before it gest started. A lot of the arguments you make would be good arguments, or would have the form of good arguments, for other features. Your "sense" of language development is good, IMO. But if you want to contribute to Python development you need to choose the features to support more in line with conventional wisdom. For example, Chris A's PEP on default argument processing (is that the PEP 671 mentioned earlier?) would resolve what many consider to be a wart, and it hasn't been rejected, just postponed. Or you could choose one that is not merely duplicating existing functionality with syntax ore to your taste. Steve