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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KLOYV2HIKJHAEJT7VCYAGYL3DUOZRGZS/
Code of Conduct: http://python.org/psf/codeofconduct/
