3 ms·

> Is there a difference between a "clever one-liner that doesnt replicate well" and idiomatic in python? 100% yes. Idiomatic would be (to me): 1. things whic

> Is there a difference between a "clever one-liner that doesnt replicate well" and idiomatic in python? 100% yes. Idiomatic would be (to me): 1. things which python does naturally - for instance list expressions rather than manual creation: managers = [ person for person in get_all_staff() if person.has_direct_reports() ] kind of thing, rather than: managers = [] for person in get_all_staff(): if person.has_direct_reports(): managers.append(person) So that's an 'idiom'. And a common one. 2. Things that Python makes natural / or less so - by the way it works. For instance, because of the important whitespace, and no end brackets or `end` keywords or whatever at the end of `if` or function definitions, large nesting inside functions becomes very klunky to follow the logic. So idiomatic would be to use small named functions, and split things into smaller pieces once they become too nested. 3. Common patterns that many people do, or common functions. See the itertools recipies, for instance: https://docs.python.org/3.5/library/itertools.html#itertools-recipes https://docs.python.org/3.5/library/itertools.html#itertools... Of course, one has to mention this: > >>> import this > The Zen of Python, by Tim Peters > > 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. > Special cases aren't special enough to break the rules. > Although practicality beats purity. > Errors should never pass silently. > Unless explicitly silenced. > In the face of ambiguity, refuse the temptation to guess. > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're Dutch. > Now is better than never. > Although never is often better than right now. > If the implementation is hard to explain, it's a bad idea. > If the implementation is easy to explain, it may be a good idea. > Namespaces are one honking great idea -- let's do more of those! So things like readability beats conciseness, so a huuuuge complex list expression is less pythonic than a manual loop when it becomes too complex.

aforwardslash 4y ago
That is actually a pretty good example of stuff that - in my opinion - hinder readability. I prefer any given day a if <something> assign; instead of assign if <something>. Maybe its because most languages I work/worked with works this way, maybe its because it forces you to read the whole line to actually understand there's an if condition. If I wanted to work with semantic english, I'd use cobol instead. >For instance, because of the important whitespace, and no end brackets or `end` keywords or whatever at the end of `if` or function definitions, large nesting inside functions becomes very klunky to follow the logic. So idiomatic would be to use small named functions, and split things into smaller pieces once they become too nested. That's not idiomatic, that is common sense, and common to basically every language. As a rule of thumb, if you have nestings grow deeper than 3-4 levels you're probably better breaking it. This is also a common cyclomatic complexity measure in most static analysis tools. Python makes following the logic clunky even in one liners, because it isn't obvious your code is not branchless. I also understand it is a matter of taste, but I do get quite annoyed with the whole "idiomatic python" thing, because often is just stuff that encourages what - in my humble opinion - are often less-than-ideal practices, that don't translate well to other languages. > So things like readability beats conciseness, so a huuuuge complex list expression is less pythonic than a manual loop when it becomes too complex. You don't need to have a huuge complex list. Imagine the example you gave, where later you need to add 2 more conditions to the if clause. What approach you think will age better between changes and refactoring? Might as well do it without list expressions from the get-go, and not having the novice developer who will be maintaining it have to read it 2 or 3 times to understand what is going on.

aforwardslash 4y ago

That is actually a pretty good example of stuff that - in my opinion - hinder readability. I prefer any given day a if <something> assign; instead of assign if <something>. Maybe its because most languages I work/worked with works this way, maybe its because it forces you to read the whole line to actually understand there's an if condition. If I wanted to work with semantic english, I'd use cobol instead. >For instance, because of the important whitespace, and no end brackets or `end` keywords or whatever at the end of `if` or function definitions, large nesting inside functions becomes very klunky to follow the logic. So idiomatic would be to use small named functions, and split things into smaller pieces once they become too nested. That's not idiomatic, that is common sense, and common to basically every language. As a rule of thumb, if you have nestings grow deeper than 3-4 levels you're probably better breaking it. This is also a common cyclomatic complexity measure in most static analysis tools. Python makes following the logic clunky even in one liners, because it isn't obvious your code is not branchless. I also understand it is a matter of taste, but I do get quite annoyed with the whole "idiomatic python" thing, because often is just stuff that encourages what - in my humble opinion - are often less-than-ideal practices, that don't translate well to other languages. > So things like readability beats conciseness, so a huuuuge complex list expression is less pythonic than a manual loop when it becomes too complex. You don't need to have a huuge complex list. Imagine the example you gave, where later you need to add 2 more conditions to the if clause. What approach you think will age better between changes and refactoring? Might as well do it without list expressions from the get-go, and not having the novice developer who will be maintaining it have to read it 2 or 3 times to understand what is going on.