5 ms·

>Two ways to delimit blocks is redundant. It isn't redundant though because without delimiting symbols for a code block you lose the ability to have your code

by sqlserver2008 4y ago

>Two ways to delimit blocks is redundant. 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.

mixmastamyk 4y ago
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.
- JohnFen 4y ago
  > Readability is definitely a strength of Python, not a weakness. I find Python to be on the lower end of average in terms of readability.
- sqlserver2008 4y ago
  >first example is a syntax error 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 https://www.youtube.com/watch?v=ubWB_ResHwM
  - mixmastamyk 4y ago
    $ 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.
    - compressedgas 4y ago
      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.
      - mixmastamyk 4y ago
        $ python3 foo.py File "~/Desktop/foo.py", line 4 print("Hello world") ^ IndentationError: unindent does not match any outer indentation level I didn't understand your statement exactly, but it doesn't seem to be true in any case.
        compressedgas 4y ago
        The file: def foo(): bar = 3 print ('4') runs fine when called as a file but when pasted into Python's REPL results in an error: >>> def foo(): ... bar = 3 ... print ('4') File "<stdin>", line 3 print ('4') ^ SyntaxError: invalid syntax However with a blank line after the definition def foo(): bar = 3 print ('4') results in: >>> def foo(): ... bar = 3 ... >>> print ('4') 4

mixmastamyk 4y ago

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.

JohnFen 4y ago
> Readability is definitely a strength of Python, not a weakness. I find Python to be on the lower end of average in terms of readability.
sqlserver2008 4y ago
>first example is a syntax error 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 https://www.youtube.com/watch?v=ubWB_ResHwM
- mixmastamyk 4y ago
  $ 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.
  - compressedgas 4y ago
    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.
    - mixmastamyk 4y ago
      $ python3 foo.py File "~/Desktop/foo.py", line 4 print("Hello world") ^ IndentationError: unindent does not match any outer indentation level I didn't understand your statement exactly, but it doesn't seem to be true in any case.
      - compressedgas 4y ago
        The file: def foo(): bar = 3 print ('4') runs fine when called as a file but when pasted into Python's REPL results in an error: >>> def foo(): ... bar = 3 ... print ('4') File "<stdin>", line 3 print ('4') ^ SyntaxError: invalid syntax However with a blank line after the definition def foo(): bar = 3 print ('4') results in: >>> def foo(): ... bar = 3 ... >>> print ('4') 4