> My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels.
This is usually due to:
1) Lack of a consistent style guide.
2) Lack of style guide enforcement.
3) A language where white space doesn't matter.
If you think about this critically though, these random indentation changes would either break all of the code (e.g. it wouldn't run, or would run but not work correctly) or it would make code maintenance a nightmare. Yet there are plenty of Python shops out there, and we don't hear horror stories of Python white space maintenance nightmares. Either the Python community is doing a good job of hiding these issues, or they really aren't issues in practice.
Of the people I've talked to in-person about Python semantic white-space, the common threads are either:
1) It's different than what I'm used to.
2) It's cramping my style. My code is art, and restricting how I can structure my code is an affront to my very being.
3) Python's semantic whitespace is so wonderful I'm baffled that most other programming languages don't have it. It's like they're coding with one eye shut: why not do this wonderful thing that makes everything easier?
2) It's cramping my style. My code is art, and restricting how I can structure my code is an affront to my very being.
To be fair, there are quite a few common cases where Python's syntax is rather inelegant. The need to break out if-then statements into multiple lines, the need for explicit 'return' statements which also have to go on their own line. These things are only indirectly related to whitespace but do sometimes put a lower bound on expressiveness.
> To be fair, there are quite a few common cases where Python's syntax is rather inelegant
Now we're stepping out of the realm of "semantic white space" though. The people I've known to get (literally) red in the face over Python haven't actually used the language and can't do much more than regurgitate stuff like, "but white space!"
> The need to break out if-then statements into multiple lines, the need for explicit 'return' statements which also have to go on their own line.
Unless I'm missing something those are poor examples of the limits of semantic white space:
Actually after a quick search I realized my problem was ignorance. I did not know about PEP 308 (conditional expressions) which is a workaround for the issue I described.
And yes technically it's a statement/expression issue not a whitespace issue, though they're indirectly related.
This is usually due to:
1) Lack of a consistent style guide.
2) Lack of style guide enforcement.
3) A language where white space doesn't matter.
If you think about this critically though, these random indentation changes would either break all of the code (e.g. it wouldn't run, or would run but not work correctly) or it would make code maintenance a nightmare. Yet there are plenty of Python shops out there, and we don't hear horror stories of Python white space maintenance nightmares. Either the Python community is doing a good job of hiding these issues, or they really aren't issues in practice.
Of the people I've talked to in-person about Python semantic white-space, the common threads are either:
1) It's different than what I'm used to.
2) It's cramping my style. My code is art, and restricting how I can structure my code is an affront to my very being.