Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>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



    $ 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.


    $ 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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: