In Python, whitespace is explicit, so actually, the bug you just posted hadn't happened if they used Python. Indeed, in your link, the braces are implicit too.
There is nothing wrong with properly indenting code. The lack of {} makes python very ugly when things no longer fit on one line. Because Python has an opinion about whitespace there are certain ways one can break a line an other ways one cannot. The result looks very ugly. Maybe the old way of using a backslash was not the worst, but linters nowadays don't like that anymore. Also having : also does not make things look better. Python must be one of the most ugly looking languages out there.
You might be already aware of this, but besides using the backslash, the other way you can allow an expression to span multiple lines in Python is to enclose it in brackets. I find this to be pretty unobtrusive. Often your line break will already be within a pair of brackets anyway.
I don't get it either. I mostly use C#, but I somehow manage to properly indent it anyway. Whenever I use python, I don't have any issues with indentation.
To me this discussion always sounds a bit like people complaining they can't find any brown underwear.
Properly indenting code is fine. Now try modifying that code, like removing an if statement inside somewhat nested code and trying to ensure that everything still has the same meaning as before. With Python, you can never be sure you did it right.
Because everyone (and all their editors) on every project have to handle indentation identically or as soon as someone makes an edit, things won't run.
Surely you don’t mean tab and vertical tab, so you must be talking about tab and… space? How would a language with no spaces look like? How do you separate tokens?
Algol 60 and Pascal had 'BEGIN ... END' to handle multiple statements in a block, but Ada and Wirth's successors, Modula-2 and Oberon, removed them except to denote where code begins in a PROCEDURE. It is much cleaner.
Poorly contrived example in Oberon:
IF n > 1 THEN
n := n * n;
RETURN 0
ELSE
RETURN 1
END
The purpose of parenthesis is too let the language know when the condition ends, and the statement begins. In a language with mandatory curly braces, the brace does that job already.
Not sure it's really that unpopular. I personally find braces harder to read. Perhaps they are more explicit, but it just adds clutter. Compared to C and Java (even well formatted) I'd rather read someone else's Python code any day.
They don’t. They stop it being an accident though - except in languages like C where braces are optional for single line blocks which can lead to similarly poor outcomes.
Whitespace sensitivity is the top of Python’s pretty exhaustive list of flaws.
Braces definitely do not stop accidents of this type, in my experience. All it takes is refactoring some code where you can’t feasibly count the number of open braces/parentheses (HCL tends to get like this), and misplacing a brace somewhere.
Until it doesn’t fit on the page anymore so you can’t see the highlight
> parser will typically fail if they are mismatched.
The concern is that your braces are technically matched, but not in the intended way, which happens a lot. Probably more than tab errors in python in my experience
I've had a team of programmers come to me and ask why some C code wasn't working after spending some time looking at it. It was a very badly formatted piece of code and yes, they were looking at the indenting rather than the braces. This was decades ago, before the rise of modern IDE's which might make such errors obvious.
To me, that was a definitive proof that while people may prefer braces over white space the majority of those same people read code, they are using indentation to guide their mental parse tree - not the braces. One obvious reason for doing that is they may not even be able to see the braces in the editor window.
It also seems obvious that the compliers should parse the same way humans do. It makes life so much simpler when we both see the same thing, so the code the compiler is emitting matches the semantic tree we are building in our heads. Which means if your goal is correct, readable code python got it right, and just about every other language gets it wrong. The article notwithstanding, there is not a lot of wriggle on that point.
Even without any editor features from the last 20 years (like auto-adding and auto-closing braces), typing semicolons and curly braces should not end up taking a significant portion of time.
Typing doesn't take a significant portion of a programmer's time anyway. Automation on that half of the work is only so useful.
Checking the code on your screen against your internal mental model does take varying amounts of time. It depends on language syntax and how your mind works.
Different programmers internally think in different ways, it turns out.
In my case I found that I tend to look at the indentation primarily, and then I check parentheses and semicolons against the indentation.
(So in my case python lets me skip an entire step.)
Indenting is not hard, and programmers should be good at it, provided they care about clean code. I like that Python forces indentation rules because it means I'll never have to read code that has confusing/improper indentation. ESLint has an indent rule to enable it for JavaScript.
I don't think I've ever craved braces in Python. I've had a few bugs due to indentation but that happens with braced languages too. If this is your preference just careful that Bython is supported into the future that you expect to use it.
I was bitten so many times by un-indented code, thanks to copy / paste that took me hours for figure out what was the actual problem.
I wish Python had closing...how do we call them, tags(?), clauses?
Anyway, here's an example of what I mean:
Before:
def IsPalindrome(s) -> bool:
for i in range(len(s)):
if s[i] != s[len(s)-1-i]:
return False
return True
print("Is Anna a palindrome?", IsPalindrome('ANNa'.lower()))
after:
def IsPalindrome(s) -> bool
for i in range(len(s))
if s[i] != s[len(s)-1-i]
return False
endif
endfor
return True
enddef
print("Is Anna a palindrome?", IsPalindrome('ANNa'.lower()))
People who don't like significant whitespace are just people who don't use a proper text editor / IDE. A lot of them think you have to manually insert the whitespace. It's the same with people who complain about parentheses in lisp.
Can we also have multi line lambdas? It will make loops in trees of components (html, UI etc) easier. Generating html in Python will look much better than:
```
with lib.html():
with lib.body():
with lib.ul():
for i in items:
with lib.li():
lib.add(i)
```
90 comments
[ 3.2 ms ] story [ 172 ms ] threadBraces are explicit, whitespace implicit.
https://embeddedgurus.com/barr-code/2014/03/apples-gotofail-...
https://en.wikipedia.org/wiki/Zen_of_Python#Principles
What are y'all doing??
That sounds like a PEP-8 violation ;)
All your lines should be under 79 characters.
Might look ugly to some but to others it looks fine.
To me this discussion always sounds a bit like people complaining they can't find any brown underwear.
Seriously, let's just prohibit any of the tab characters(^I,^K,^L) in source code.
Or more seriously like any of the existing slightly more sane languages that don't need spaces, like the Lambda Calculus.
Poorly contrived example in Oberon:
if x = 5 then writeln;
Happy hacking!
If you can call 2021 recent, that is.
[1] https://docs.scala-lang.org/scala3/reference/other-new-featu...
Won't fly with Python's "one way to do it" principle though.
from __future__ import braces
I just wrote my code as normal (indented, thank you very much) and could ignore semicolons and curly braces, and the code just ran.
I was done in half the time!
This seems like a regression by people who are bad at indenting their code. ;-)
(see also: https://pypi.org/project/goto-statement/ )
b) When reformatting code like
you're liable to make a typo and commit a grave logic error.Whitespace sensitivity is the top of Python’s pretty exhaustive list of flaws.
HCL is fine for this. Editors highlight matching braces, typically, and the parser will typically fail if they are mismatched.
Until it doesn’t fit on the page anymore so you can’t see the highlight
> parser will typically fail if they are mismatched.
The concern is that your braces are technically matched, but not in the intended way, which happens a lot. Probably more than tab errors in python in my experience
So there's arguments either way.
Now that I'm used to it, I do feel that indentation errors (or at least an indentation/paren mismatch) should probably be a syntax error either way.
Possibly people who argue for belts and suspenders might be on to something?
To me, that was a definitive proof that while people may prefer braces over white space the majority of those same people read code, they are using indentation to guide their mental parse tree - not the braces. One obvious reason for doing that is they may not even be able to see the braces in the editor window.
It also seems obvious that the compliers should parse the same way humans do. It makes life so much simpler when we both see the same thing, so the code the compiler is emitting matches the semantic tree we are building in our heads. Which means if your goal is correct, readable code python got it right, and just about every other language gets it wrong. The article notwithstanding, there is not a lot of wriggle on that point.
Checking the code on your screen against your internal mental model does take varying amounts of time. It depends on language syntax and how your mind works.
Different programmers internally think in different ways, it turns out.
In my case I found that I tend to look at the indentation primarily, and then I check parentheses and semicolons against the indentation.
(So in my case python lets me skip an entire step.)
But nowadays it's autocompleted anyway.
I put the cursor over a curly bracket, press CTRL-M, the cursor navigates to the other curly bracket.
My eyes also parse code much faster when it is both indented and with proper brackets.
Python just makes more difficult some common tasks like commenting out a try/catch block without having to reindent all the code inside.
Not a win IMO. In fact, Python presumes it is easier to use, while in reality, it is not.
I wish Python had closing...how do we call them, tags(?), clauses?
Anyway, here's an example of what I mean:
Before:
after:I love how concise and clean Python looks. I would rather see other languages removing brackets.
Not having braces makes python very easy to teach where the keyboard layouts do not favour those characters accessibility.
``` with lib.html(): with lib.body(): with lib.ul(): for i in items: with lib.li(): lib.add(i) ```