Yeh, pretty much anything here that has a colon is an unreadable, worthless one liner, except maybe for helping copy/paste to run it with python -c "bad_one_liner; some_other_function()
And anything that tries to take advantage of a list comprehension or conditional/ternary assignment for the side effects, like 2 and 15, makes me cringe hard.
Though these can arguably fixed and can even be useful for long expressions, especially when used to the extra whitespace of the black formatter. Interestingly with things like this, it is often only readable with long variable names that force line splits. Each proposed alternative will be copied as a one-liner at the end.
2. Honestly chaining conditional assignments just looks bad, but at least this actually uses expressions and doesn't rely on side effects.
print(
"no"
if x > 42
else "yes"
if x == 42
else "maybe"
)
And for good measure, here is an interesting yet even less readable way. You don't even need the inner parens, but then its even worse.
print(
(x > 42 and "no")
or (x == 42 and "yes")
or "maybe"
)
15. Thinking about which is the outer and inner loop makes anything like this a bit awkward
print(
*[
f"{x} {y}"
for x in iter1
for y in iter2
],
sep="\n"
)
Alternatively, using "".join()
print(
"\n".join(
f"{x} {y}"
for x in iter1
for y in iter2
)
)
In this case you can use itertools.product which might make it clear that youre iterating over the cartesian product, instead of having to mentally unwrap a nested for loop
from itertools import product
print(
*[
f"{x} {y}"
for x, y in product(iter1, iter2)
],
sep="\n"
)
As promised, each as a one-liner. Im not sure I did anything to improve readability.
2.
print("no" if x > 42 else "yes" if x == 42 else "maybe")
print((x > 42 and "no") or (x == 42 and "yes") or "maybe")
15.
print(*[f"{x} {y}" for x in iter1 for y in iter2], sep="\n")
print("\n".join(f"{x} {y}" for x in iter1 for y in iter2))
print(*[f"{x} {y}" for x, y in product(iter1, iter2)], sep="\n")
print("\n".join(f"{x} {y}" for x, y in product(iter1, iter2)))
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great idea for an article. 11 and 14 seem quite interesting. However:
At least 2,4,8,12,13 and 17 are absolute no-go for an interview. You can impress your friends with them, but never ever use them again.
You should consider removing them from the article or mark them somehow. Experienced developer will just laugh at it, begginer may learn a bad habit.
Thanks for reading!
Yeh, pretty much anything here that has a colon is an unreadable, worthless one liner, except maybe for helping copy/paste to run it with
python -c "bad_one_liner; some_other_function()
And anything that tries to take advantage of a list comprehension or conditional/ternary assignment for the side effects, like 2 and 15, makes me cringe hard.
Though these can arguably fixed and can even be useful for long expressions, especially when used to the extra whitespace of the
black
formatter. Interestingly with things like this, it is often only readable with long variable names that force line splits. Each proposed alternative will be copied as a one-liner at the end.2. Honestly chaining conditional assignments just looks bad, but at least this actually uses expressions and doesn't rely on side effects.
And for good measure, here is an interesting yet even less readable way. You don't even need the inner parens, but then its even worse.
15. Thinking about which is the outer and inner loop makes anything like this a bit awkward
Alternatively, using "".join()
In this case you can use itertools.product which might make it clear that youre iterating over the cartesian product, instead of having to mentally unwrap a nested for loop
As promised, each as a one-liner. Im not sure I did anything to improve readability.
2.
15.