DEV Community

18 Python one-liners that will speed up your coding process.

Yash Makan on November 23, 2021

Please don't use these one liners in any interview, or in any production based code. The article is just for fun seeing the replacement of some pr...

Read full post

𒎏Wii 🏳️‍⚧️ • Nov 23 '21

This will help you to write the code faster. You can write the piece of code much faster than others which will help you in competitive programming.

Any programmer that is mainly limited by their typing speed should seriously consider a career change.

Ivan Iliukhin • Nov 27 '21

In competitive programming, every second matters. But, yes, in production these fragments are not acceptable. Readability of a codebase is much more important.

AdiNar • Nov 23 '21

Great idea for an article. 11 and 14 seem quite interesting. However:

You can impress your friends, colleagues and you can give a good impression in your interview if you have a good grasp of one-liners.

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.

zrsmithson • Nov 24 '21

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.

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)))

Yash Makan • Nov 24 '21

Thanks for reading!

Amal Shaji • Nov 23 '21

Do not assign a lambda expression, use a def (E731). Most of these one-liners will be flagged by code quality tools.

Thomas Junkツ • Nov 24 '21 • Edited

The thing with clever code is: Most of the time you have to be twice as clever to debug it than to write it.

So don't be too clever when writing it and give yourself a chance of debugging it in the future.

xtofl • Nov 27 '21

Worse: everybody coming after you has to be. Of course, OP warned us in the introduction :).

Yash Makan • Nov 23 '21

I have added a note on the top of the Article to not use these one liner in any production based projects as the code becomes less readable. The article is just for exploring different ways of reducing the code size and for fun... If anybody is offended by the article then I am sorry and will take care of this in my future articles
Thanks

Stephen J. Michaele • Nov 23 '21

The article isn't offensive, Yash. Much of it just doesn't represent good coding practices so I'm glad you added the note at the top. As professional developers we need to be careful what advice we give to those with less experience. Keep sharing!

Yash Makan • Nov 24 '21

Yes! I agree with you. Thanks

Jean-Michel Plourde • Dec 29 '21

It breaks the first few lines of the Zen of Python - PEP20

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.

Hunter Morris • Nov 24 '21

Interesting post! At work, I'm often just looking for quick ways to parse a one-off dataset or other small things like that, and it doesn't have to be readable or maintained by anyone but myself, so I use several of these (admittedly non-Pythonic) schemes. Writing for a team is different. This is still quite useful, especially to learn the extent of some of the nuanced features that this language has. Cheers.

print(*range(1,5)) didn't work for me (running Python 3.10), but Walrus:= taught me a new trick and I will definitely be using it.

Yash Makan • Nov 24 '21

Glad I could help. Thanks for reading

ElVi2 • Nov 24 '21

As someone who used these in the past during her studies, I personally would say that while they make the code more compact, depending on the situation they may also potentially compromise debugging and overall readability, especially if one uses a lot of them (I got a lot of complaints from teachers about my code being hard to follow when I was using a lot of one-line loops and had to rewrite them on spot). So I think at least a few of these are pretty situational IMO.

Bernd Wechner • Nov 24 '21

If you're going to toy with one-liners like this and justify it on the basis of learning (as most of these are not good practice as others have noted) then I'd suggest you add a little explanatory commentary to the one-liners. I mean for example a few of them are just standard list comprehensions but you don't mention that anywhere and that's a useful piece of vocabulary for a wannabe Python coder and you could group those under an embracing heading of "list comprehensions".

Just a thought.

Yash Makan • Nov 24 '21

Thanks for the note advice. Added the quote on top.

Casper • Nov 25 '21

Others have already pointed out that a lot of these are bad ideas, I would like to add one thing. While ternary if's, list comprehension and lambdas are cool, they are not equivalent to their regular variants. Once you have an if-statement with two statements inside it you can no longer convert it into a ternary. Same applies to list comprehension and lambdas. They are all basically simpler and more restricted versions of the regular variants, and have a more specific use-case. If you do not know when to use them it is better to avoid them rather than trying to squeeze them in wherever possible.

matthew-salerno • Nov 24 '21

These are certainly some dangerous tools, and I'm bound to misuse them in the future just I have in the past. However, that doesn't mean it's not worth exploring. I find some one liners easier to follow than more verbose versions, and the conciseness can be especially helpful as well. In practice, I don't think one liners have as much to do with compactness and readability as it is about how you approach the problem. Sometimes problems are easier to think about in a more mathematical sense, such as graph traversal or parsing. When this happens I find the conciseness of one liners very helpful. Likely because most of the tools that enable them were borrowed from functional languages like Haskell.
Admittedly, my hipster impulse to abuse the most obscure parts of a language does not make good code, at best it makes fun code. So maybe take what I say with a grain of salt.