DEV Community

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

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...
Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

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.

Collapse
 
evanilukhin profile image
Ivan Iliukhin

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

Collapse
 
adinar profile image
AdiNar

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.

Collapse
 
zrsmithson profile image
zrsmithson

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"
)
Enter fullscreen mode Exit fullscreen mode

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"
) 
Enter fullscreen mode Exit fullscreen mode

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"
) 
Enter fullscreen mode Exit fullscreen mode

Alternatively, using "".join()

print(
    "\n".join(
        f"{x} {y}"
        for x in iter1
        for y in iter2
    )
) 
Enter fullscreen mode Exit fullscreen mode

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"
) 
Enter fullscreen mode Exit fullscreen mode

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") 
Enter fullscreen mode Exit fullscreen mode

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)))
Enter fullscreen mode Exit fullscreen mode
Collapse
 
yash_makan profile image
Yash Makan

Thanks for reading!

Collapse
 
amal profile image
Amal Shaji

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

Collapse
 
thomasjunkos profile image
Thomas Junkツ • 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.

Collapse
 
xtofl profile image
xtofl

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

Collapse
 
yash_makan profile image
Yash Makan

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

Collapse
 
smichaele profile image
Stephen J. Michaele

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!

Collapse
 
yash_makan profile image
Yash Makan

Yes! I agree with you. Thanks

Collapse
 
jmplourde profile image
Jean-Michel Plourde

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.
Enter fullscreen mode Exit fullscreen mode
Collapse
 
hmorris94 profile image
Hunter Morris

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.

Collapse
 
yash_makan profile image
Yash Makan

Glad I could help. Thanks for reading

Collapse
 
elvi2 profile image
ElVi2

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.

Collapse
 
thumbone profile image
Bernd Wechner

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.

Collapse
 
yash_makan profile image
Yash Makan

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

Collapse
 
cappe987 profile image
Casper

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.

Collapse
 
matthewsalerno profile image
matthew-salerno

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.

Collapse
 
yash_makan profile image
Yash Makan

Thanks for reading! 😊

Collapse
 
rostemelov profile image
Rostemelov

Really helpful for a noob like me... Thanks 😊👍

Collapse
 
yash_makan profile image
Yash Makan

We are all learning @rostemelov . Thanks for reading...

Collapse
 
salabim profile image
salabim

Example 2 can be written more compact:
print("no", "maybe", "yes")[(x < 42) -(x > 42) + 1]
, which is arguably easier to read.

Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

You just agreed with me though. I'm confused.

Collapse
 
machinesrental profile image
machinesrental

When I see this hardly readable code, I like Typescript much more than before 😎

Collapse
 
t_rakibul profile image
Md. Rakibul Islam

Great article 👌👍.
Thanks 😊

Collapse
 
yash_makan profile image
Yash Makan

Glad I could help!