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...
For further actions, you may consider blocking this person and/or reporting abuse
Any programmer that is mainly limited by their typing speed should seriously consider a career change.
In competitive programming, every second matters. But, yes, in production these fragments are not acceptable. Readability of a codebase is much more important.
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.
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.
Thanks for reading!
Do not assign a lambda expression, use a def (E731). Most of these one-liners will be flagged by code quality tools.
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.
Worse: everybody coming after you has to be. Of course, OP warned us in the introduction :).
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
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!
Yes! I agree with you. Thanks
It breaks the first few lines of the Zen of Python - PEP20
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.
Glad I could help. Thanks for reading
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.
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.
Thanks for the note advice. Added the quote on top.
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.
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.
Thanks for reading! 😊
Really helpful for a noob like me... Thanks 😊👍
We are all learning @rostemelov . Thanks for reading...
Example 2 can be written more compact:
print("no", "maybe", "yes")[(x < 42) -(x > 42) + 1]
, which is arguably easier to read.
You just agreed with me though. I'm confused.
When I see this hardly readable code, I like Typescript much more than before 😎
Great article 👌👍.
Thanks 😊
Glad I could help!