It isn't redundant though because without delimiting symbols for a code block you lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point:
def example():
x = 5
print("Hello world")
What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline before it. The point is you (and any formatting tool) can't know what the horizontal alignment of this code should be just by examining the vertical line order. You can only determine this by knowing (or reanalyzing) the semantics of the code. During a refactor where you're moving around lots of code, this can be a significant PITA. However, in the JS example,
function example() {
let x = 5
console.log("Hello world")
}
it's unambiguous what the mistake is because you can determine the correct formatting entirely from the line order, without having to know anything about the code's semantics.
The first example is a syntax error, which must be fixed, and takes a second. Not a PITA, just a part of normal day to day refactoring.
I see how a formatter could help you out in this specific situation. However you are trading typing of redundant characters every few seconds and readability per minute, to avoid an issue that happens once or twice a day, per week on a mature project.
In other words we generally don’t significantly reorganize code nearly as much as reading, tweaking, adding features etc.
Readability is definitely a strength of Python, not a weakness. A lot of this is because of reduction of required notation.
The code runs so it's most definitely not a syntax error. May be against PEP styling rules, but it is valid Python code.
>which must be fixed, and takes a second.
And that was my earlier point. The responsibility to get the code in a state where it is formatted AND runnable falls entirely on you, as this work cannot be entirely delegated to software when the syntax uses significant indentation. And the fixing of the code would require you to reanalyze the code's semantics before you would even know what the appropriate fix is. Of course it would only take a second for a trivial example like the one I used, but real Python codebases aren't going to be trivial.
>typing of redundant characters
It actually doesn't require any additional typing as compared to Python. In modern editors the closing brace is automatically added when you type the opening brace. So you simply type the opening brace and hit enter, just as you would type the colon and hit enter in Python. Even the space between the closing parenthesis and opening brace in the function header is added automatically by formatters.
>readability per minute
Seems pretty subjective but I don't think there's a significant difference in readability between Python and braced languages, or even between Python and languages that use block delimiters other than braces, like Ruby. A lot of readability comes down to personal familiarity with a language.
>we generally don’t significantly reorganize code nearly as much as reading, tweaking, adding features etc.
Totally agree, and I think this is one of the big problems of software development. People generally don't want to make big reorganizational changes to code and instead prefer to change the code only through additions. As a result, legacy projects tend to accrete layers of cruft over time whether it is necessary or not. I'm not a Jonathan Blow fanboy by any means, but I recently saw this clip which I think makes a good point.
https://www.youtube.com/watch?v=ubWB_ResHwM
$ python3
Python 3.10.6 (...snip...)
>>> def example():
... x = 5
... print("Hello world")
File "<stdin>", line 3
print("Hello world")
^
IndentationError: unindent does not match any outer indentation level
Sort of an odd video, haha. But I liked the guy... think we could be friends. ;-)
It's idea is sort of neither here nor there however, regarding whitespace blocks. That we "rent" more often than own is just a reality of the system we find ourselves in. (For example cheap products sell more than expensive ones and that is expected and ok.)
I don't want to optimize my projects around large refactors since I only do it a few times per project, but will read it often.
That's because the REPL has the additional restriction of requiring a definition (or any top level indented block) to end with an blank line. This restriction does not apply when running code from a file.
I see now. The issue was pasting the snippet into a terminal added an extra level of indentation from the post (pre must be indented). This changed the result.
This also lines up with my anecdotal experience, and the best boring food I've ever found were potatoes. I used to avoid them because of the carb content, but they always seem to give me good energy while also being 'filling'. If you look up various satiety indices, potatoes always seem to be at the top, even higher than most meats.
With regular consumption, I've found simple, unprocessed potatoes to become very boring even while being very satiating. It's strange, like I have this strong psychological urge to consume something with more exciting flavor to it (i.e. processed food) while being completely satisfied physically. Regardless, I think it's a food that can really help people who struggle to lose weight.
Indentation-sensitive syntax is totally obsolete in a world with autoformatters. In addition, with this kind of syntax you also lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point:
def example():
x = 5
print("Hello world")
What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline before it. The point is you (and any formatting tool) can't know what the horizontal alignment of this code should be just by examining the vertical line order. You can only determine this by knowing (or reanalyzing) the semantics of the code. During a refactor where you're moving around lots of code, this can be a significant PITA. However, in the JS example,
function example() {
let x = 5
console.log("Hello world")
}
it's unambiguous what the mistake is because you can determine the correct formatting entirely from the line order, without having to know anything about the code's semantics.
This is a really good point, but one still doesn't need curly braces and semis. Despite having a lightweight syntax, OCaml isn't indentation sensitive, so doesn't suffer from this. The Ocamlformat tool also works really well.
> OCaml isn't indentation sensitive, so doesn't suffer from this
True, I was just making the point that the lightweight syntax of indentation-sensitive languages like Python can be problematic. I don't know how OCaml is able to achieve this style of syntax without the use of significant indentation, but it is impressive.
It isn't redundant though because without delimiting symbols for a code block you lose the ability to have your code autoformatted in certain situations. Here's a trivial example to illustrate the point:
What's the mistake here? Depending on whether the print is part of the function, it should either be indented or have a newline before it. The point is you (and any formatting tool) can't know what the horizontal alignment of this code should be just by examining the vertical line order. You can only determine this by knowing (or reanalyzing) the semantics of the code. During a refactor where you're moving around lots of code, this can be a significant PITA. However, in the JS example, it's unambiguous what the mistake is because you can determine the correct formatting entirely from the line order, without having to know anything about the code's semantics.