Bython: Python with braces. Because Python is awesome, but whitespace is awful
pypi.org
pypi.org
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
for a in x:
f(a)
if something:
g()
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
for (let a of x) {
f(a);
if (something) {
g();
}
}
If you're a programmer who looks primarily at indentation for their syntax cues, it's the parens that can lead you into traps.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:
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())) def IsPalindrome(s) -> bool
for i in range(len(s))
if s[i] != s[len(s)-1-i]
return False;
;
return True;
I'd also be inclined to skip it for 'def' as well, since they tend not be be as nested.Braces are explicit, whitespace implicit.
https://embeddedgurus.com/barr-code/2014/03/apples-gotofail-...
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.
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.
Not having braces makes python very easy to teach where the keyboard layouts do not favour those characters accessibility.
if __name__ == "__main__" {
print_message(10);
}
This just looks wrong without parenthesis around the conditional statement.if x = 5 then writeln;
Happy hacking!
I love how concise and clean Python looks. I would rather see other languages removing brackets.
``` with lib.html(): with lib.body(): with lib.ul(): for i in items: with lib.li(): lib.add(i) ```
$ python3 -c 'from __future__ import braces'
File "<string>", line 1
SyntaxError: not a chance
$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 n > 1 THEN
n := n * n;
RETURN 0
ELSE
RETURN 1
ENDfrom __future__ import braces
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance