Dom Grigonis writes:
But "encourages one-liners" is generally considered an anti-pattern in Python. Let's see why,
Here I am a bit confused, how is this the case in the language containing list comprehensions?
I don't think of list comprehensions in terms of line count. I often write multiple-line list comprehensions and genexps. Especially when nested or with an 'if' clause,, I often use multiple lines even though the whole thing would fit on a single line because I feel it expresses the structure better. Comprehensions and genexps are an especially nice context for that, because they are always equipped with parentheses, so you are not constrained by the usual rules of indentation, and don't need line continuing backslashes. Also consider for x in list1: list2.append(foo(x)) list2.extend([foo(x) for x in list1]) The second form is one character less concise than the former, yet far more expressive. Once genexps were introduced, we could make it one character more concise than the for loop with list2.extend(foo(x) for x in list1) but it's unclear that this is an improvement over the list comprehension. (That's probably due to the facts that I don't use genexps that often, and that I think of list.extend as a concatenation of lists even though it's documented as taking an iterable. If most people have more facility with genexps than I do, it's a small but clear improvement.)
I would understand if it was swapped with “bad quality & unreadable 1-liners”.
That dodges the question of when does a one-liner cross over to "bad quality and unreadable", though.
Also, I would rephrase “encourage 1-liners” to “promote readable and expressive structures that are balanced in their brevity versus complexity”. I am not encouraging 1-liners,
Well, the word "one-liner" has a history. "One-liner" is a category by that name in the Obfuscated C Contest, and Perl programmers often take pride in how much they can accomplish on the command line, without starting an editor or interactive interpreter. Some of us old-timers are going to take it the wrong way. I'm not sure if less indoctrinated people would take it to mean "readable and expressive structures that are balanced in their brevity versus complexity". :-) In any case, whether you intend it or not, making the ternary expression more terse would encourage examples of the kind you present.
I am more arguing that certain things in relation to average complexity should take no more than 1-line. I am always very happy to write multiple lines.
A Python ternary expression usually takes only part of one line. They allow you to put a simple conditional in the middle of a longer expression. However, they're not amenable to nesting ternaries, except in very special circumstances. I think that's a good thing, you don't. We can both be right, you know! I'm just trying to explain why I think that way, and making the claim (which may be incorrect) that the Pythonistas who influence language design do, too.
Btw, here I would probably prefer: def clamp_int(n: int, lo: int, hi: int): if lo > hi: raise ValueError(f'{lo=} > {hi=}') return lo <= n <= hi ? n : (n > hi ? hi : lo)
To my eye, that's a great example of "concise but not expressive". Parsing it requires reading almost character by character, the nuance of the conditional changes from "True => usual case" to a genuine choice, and verifying the correctness of the expression is nontrivial compared to verifying the if statement form.
I think the place I am coming from is more about balance than brevity.
OK. But for me that's hard to see when it's expressed by counting lines. Balance and nuance sometimes can be expressed in words, but in cases where the line is hard to draw, we often go through a large corpus and find as many examples as possible and compare the existing code with versions using the new syntax. Typically it's the stdlib, but since you mention numerical analysis, numpy or something based on it like pandas might provide better examples for you. I don't recommend that here. The existence of a semantically equivalent ternary expression already makes that an impossible lift. Steve