[makmanalp]

Nice overview. I think a lot of the tenets of pythonicness are based on the heuristic that there should be minimal cruft and friction between the reader and the code. I should be looking at a reasonably close approximation of my interpretation of the problem. Was it let or var? Semicolon or no semicolon? Was it := or set! <- or <<- ? Squiggly braces or none? Does the second indented line after a non-squiggly block count as part of the block? Was it private static or static private? Does const go before or after the function definition? Does i++ increment first or provide a value first? I should have to think less about any of these things and more about the problem.

Usually, syntax is minimal enough to get out of your way, and where there is syntax, it attempts to be consistent and to enforce clarity.

[jimmaswell]

In most of those cases there's no point thinking of them, just type the first one that comes to mind and move on

[gmu3]

I hate poorly styled code. Edit: I don't know why I'm being downvoted for this. That kind of mentality inherently churns out bad code.

[jimmaswell]

They're all inconsequential to code quality except for some like i++ vs ++i which isn't even style, it's syntax. preincrement before, postincrement after, not hard to remember

[gmu3]

Syntax and style are tightly coupled in Python. It's not hard to remember i++ is the same as i+=1 or that if(bool) { can optionally have a line break between the guard and the brace. In other languages, you have more choices. If you have more choices and just type what comes to mind first, you're going to get stylistic inconsistencies.