This comment is very critical, but is not meant to be hostile.
The objective should be clarity, not brevity. Writing shorter code is good only to the extent that it makes the code more readable. "Tricks" in general tend to be obscure, make the writer feel clever, and confuse the reader. Even something like slicing's step parameter should often be explained when it's used.
I recommend people learning python read Google's python style guide to understand the reasoning, not necessarily to follow. They would not encourage a nested comprehension for product. google.github.io/styleguide/pyguid...
"a real Python professional will only laugh at you." The passages like this bother me.
Comprehensions are not dogmatically correct, and someone laughing at a beginner for not using advanced features should not be the face of "real python professionals".
With that out of the way, I think these are useful things to know.
In general I'd advise someone to learn by googling what they're trying to do (eg python remove duplicates from list), look at top answers, and consider what is clearest.
So agree. I read this article with only thought - those explicit code, which author claims as junior's often is much more readable than suggested oneliners. And claims like "a real competent Python developer code" e.t.c are controversial for me. My experience reading code of a real highly experienced and clever professionals tells me that they usually tend to the simplest and most explicit solution possible. Their code is easy to read and understand. But tricky things usually appear because of ego and lack of self confidence as a professional. Real professional developer visible by his patterns, architecture and code style, not by some tricks.
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.
This comment is very critical, but is not meant to be hostile.
The objective should be clarity, not brevity. Writing shorter code is good only to the extent that it makes the code more readable. "Tricks" in general tend to be obscure, make the writer feel clever, and confuse the reader. Even something like slicing's step parameter should often be explained when it's used.
I recommend people learning python read Google's python style guide to understand the reasoning, not necessarily to follow. They would not encourage a nested comprehension for product. google.github.io/styleguide/pyguid...
"a real Python professional will only laugh at you." The passages like this bother me.
Comprehensions are not dogmatically correct, and someone laughing at a beginner for not using advanced features should not be the face of "real python professionals".
With that out of the way, I think these are useful things to know.
In general I'd advise someone to learn by googling what they're trying to do (eg python remove duplicates from list), look at top answers, and consider what is clearest.
So agree. I read this article with only thought - those explicit code, which author claims as junior's often is much more readable than suggested oneliners. And claims like "a real competent Python developer code" e.t.c are controversial for me. My experience reading code of a real highly experienced and clever professionals tells me that they usually tend to the simplest and most explicit solution possible. Their code is easy to read and understand. But tricky things usually appear because of ego and lack of self confidence as a professional. Real professional developer visible by his patterns, architecture and code style, not by some tricks.