Hacker News Reader

Comment by jacquesm | Hacker News Reader

No, it goes beyond taste. The inability to reliably cut-and-paste example code and the total mess you get when people have combined spaces and tabs which could result in ambiguous code is a danger that could have been side-stepped quite handily.

It's like driving on the autobahn without guardrails. You may only need them once or twice in your life and yet, you're happy the guardrails are there. Just in case.

Allowing both tabs and spaces was simply a mistake but it is too late to turn the clock back on that now.

http://wiki.c2.com/?PythonWhiteSpaceDiscussion

In general, significant whitespace isn't fantastic but at least now we have widespread version control which helps in case of accidental deletion/insertion of a space or a tab or a newline.

View on HN

Yes, but having to do a git diff to verify if I refactored a function correctly is telling about the shortcomings in the design of the language. Indentation should be left to the editor: RETURN starts a line at the correct indentation level (one more after a : ) and anything convenient to decrease indentation (example: TAB TAB in emacs)

This is my major pain point with Python. No code blocks as arguments and single line lambdas are the second one.

And those underscore looks so 80s, but that's when van Rossum started designing Python. Same thing for the self argument in method definition: it's the pointer to the struct holding the function pointers and instance variables in object oriented C (without ++).

On the other side

   object = ClassName()

is more convenient than

   object = ClassName.new # Ruby
   object = new ClassName(); // Java

Editors have nothing to do with this. You have dirty coders everywhere on the net.

Having to edit a bit a code you copy paste from an badly formatted source (which you should do anyway for safety) is a small price to pay to avoid all the dirty coders in the world to write blocks with a showel.

It's not from a badly formatted source: it's my well formatted working code. I just did it a couple of minutes ago: I added an indentation level into a function and went TAB, ARROW DOWN through 10 lines of codes in emacs. There was a try except in that code and I had to pay attention to the line after the end of the except block.

I know that I should select the region and do C-c > to move it one level to the right, but it's not convenient. In any other language the editor indents it with one keystroke (actually it's 3 keystrokes: C-M-\ because it's emacs...) That's why TAB, ARROW DOWN is faster, when it doesn't add bugs.

Why is everything so compliated in emacs ? Sublime text, pycharm and vscode all handle that fine automatically.

You have the same problem of space/tabs in all other languages, except there is no error and it can silently mislead you in badly understanding code, or just make it harder to read for hours on big project created by several generations of dev.

No, in (almost) all other mainstream languages you have some kind of block-end block-start markers. {} or begin end or whatever the language uses. Significant whitespace was considered a bad idea in days long past but that lesson was forgotten.

So Python has ... nothing. I program a lot in Python but this is one headache I could have done without. It also always makes me read a little bit further than I have to when looking at some block of code because you never know that something else might follow until you drop that indentation level back down. So now you have to count indentation levels.

>No, in (almost) all other mainstream languages you have some kind of block-end block-start markers. {}

And in many languages, those are optional in certain contexts (as someone else mentioned: see heartbleed).

Yes, and in the 'optional' case the accidents happen, which should be a quiet hint that they should not be optional.

   if (a == b) 
        do_this()

        and_always_dothis()

...

Totally agree. They should never be optional, either force them always or don't have them at all (like Python). Your code example wouldn't confuse anyone in Python as he knows that and_always_dothis() is inside the if.

"""Significant whitespace was considered a bad idea in days long past but that lesson was forgotten."""

Who exactly considered it a bad idea and why?

>The inability to reliably cut-and-paste example code and the total mess you get when people have combined spaces and tabs which could result in ambiguous code is a danger that could have been side-stepped quite handily.

I have never encountered either of these problems, pasing issues are trivially solvable ("+p), and who uses tabs?

Just to counter your single anecdote with mine: I have on multiple occasions run in to syntax errors when copying/pasting code from sources that didn't properly preserve whitespace. It was fixable, but annoying.

I also often run in to code that mixes tabs and spaces, not just in Python, but it many other languages as well, and it is super annoying when it happens.

That said, before I learned Python, I absolutely hated the idea of meaningful, forced whitespace. But once I actually learned Python, it turned out it wasn't a big deal, as I tended to indent that way anyway. But it is annoying on occasion when working with other people's code, for the reasons mentioned.

Reply on news.ycombinator.com