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