That just encourages bad behaviour in the other direction though. A massive multi-level nested ternary on one line is usually going to be worse than a longer but clearer set of conditions. Trying to make code brief can be good, but it can often result in an unmaintainable and hard to read mess.

That results in the same AST, it's not really taking anything away

Except for readability

Halstead complexity ([0]) might interest you. It's a semi-secret sauce based on the count of operators and operands that tells you if your function is "shitty".

[0]: https://en.wikipedia.org/wiki/Halstead_complexity_measures

You'll never get it right though. Focusing on "features per LOC" means people will write shorthand, convoluted code, pick obscure, compact languages, etc. To use an adage, if a metric becomes a target, it stops being a useful metric.

An opinionated formatter plus a smart line counter fix this problem. There's still space for abuse but not enough to overshadow genuine improvements.

How does a formatter affect me intentionally writing more (or less) lines for the sake of reaching a line count?

print([i * 2 for i in range(10)])

vs

squared_numbers = []

for i in range(10):

    squared_numbers.append(i \* 2)

print(squared_numbers)

It's not even a readability thing, assuming list comprehensions don't bother you they're about equally readable

You can write more but you can't write less!