Yes, I think so. The downside with Python comes when refactoring the code. There’s always this double checking if the code is correctly indented after the refactor. Sometimes small mistakes creep in.
It’s really hard to tell when Python code is incorrectly indented. It’s often still valid Python code, but you can’t tell if it’s wrong unless you know the intention of the code.
In order languages it’s always obvious when code is incorrectly indented. There’s no ambiguity.
It’s only hard to tell indentation in Python when the code block gets longer than about a screen, which is usually a sign the code should be refactored into smaller methods.
As someone who has been working in Python a ton for the last couple years, it’s amusing to me how many downvotes you’re getting for simply noting that good code style and tight, terse, modularized implementation of business logic more or less addresses the issue. Because it absolutely does in the vast majority of cases.
Yes it would - look at optional braces for short if expressions in C family languages and why it's so discouraged in large projects. Terminating characters are absolutely worth the cost of an extra LoC
That misleading behavior does happen in Python. The next programmer that comes along can’t tell if the original programmer fucked it up and didn’t unindent to put a statement outside of the block or if they meant to put it inside the block. I’ve debugged this one too many times and it takes hours each time because it’s impossible to see the bug at all!!
I don’t agree. It’s a direct result of whitespace, which does not happen if you don’t use whitespace. For example it can happen in Java and kotlin, but only if you use if statements without braces, which you pretty much never see. If you do see it you know to look out for the exact issue I described. That’s not possible in Python, since there is no alternative.
Indentation can be (and should be) tabs, EOL is it's its own thing either \n or CRLF which Python source code did actually care about as recently as 2.3.
Assumptions like this is why most people should stick to verbose languages with lots of guardrail braces.
YAML sucks because, among other things, indenting it is not obvious.
In contrast, the only mistake of Python when it comes to whitespaces was allowing hard tabs, which makes it too easy to mix them if your editor is not configured.
Improper indentation stands out more than missing or unbalanced braces and it's really not an issue to delimit code blocks.
Haskell supports both semantic whitespace and explicit delimiters, and somehow almost everybody that uses the language disagrees with you.
But anyway, for all the problems of YAML, this one isn't even relevant enough to point out. Even if you agree it's a problem. (And I agree that the YAML semantic whitespace is horrible.) If YAML was a much better language, it would be worth arguing whether semantic whitespace breaks it or not.
Not any language. I code professionally in F# which has semantic whitespace and it has literally never been an issue for me or my team. In contrast to Python, it’s a compiled language and the compiler is quite strict, so that probably helps.