[simias]

> Getting the indentation right should be the least of your worries if you have a good editor

I never understood that. The whole problem for me is that the indentation being the only thing denoting blocks the editor can't know for sure how things should be indented, since it's not simply cosmetic.

I haven't written a whole lot of Python but how do you even refactor python code? In C I can just copy paste a block of code from anywhere to anywhere (no matter the coding style in the source and destination file and the level of indentation) and then hit C-M-\ in emacs and have it reindent everything properly. In Python you have to make sure that everything is at the level of indentation it belongs to. If you refactor huge chunks of code it's easy to miss one fubar tab and have code subtly broken and introduce weird regressions.

Also, regarding the OP and "focusing only on your code", I think we all feel that way about the language we're the most familiar with. For me that's C and I can't say I've had a "missing semicolon" compilation error in months of heavy use. Once you're used to the syntax it becomes automatic.

[pyre]

> If refactor huge chunks of code it's easy to miss one fubar tab and have code subtly broken and introduce weird regressions.

That is just one of the many issues that can come up when refactoring large sections of code, and is one reason that people write tests. For people to point it out as the entire reason that they can't use Python seems to be making a mountain out of a mole hill.

For example, I don't like that I can't use "if $?" in Ruby and I need to explicitly write "if $? != 0", but I don't go around bashing Ruby on that basis. For some reason people feel that need to do that with Python though. I don't really understand it.

[simias]

I'm not making a mountain out of a molehill but I don't understand why the python crowd refuse to acknowledge that having significant whitespace does cause some issues and the benefits are completely subjective.

Sure unit tests will catch the error but in most other languages the error wouldn't have been introduced in the first place.

I think in the end the problem is that I've been writing in C-style languages a long enough time that I don't even "see" the brackets and semicolon anymore. As such I don't find any advantage to the python way. To me it's sacrificing convenience for aesthetics.

[pyre]

> I'm not making a mountain out of a molehill

I'm not saying that you are, just that these arguments/discussions generally are making a mountain out of a mole hill when people go on at length about how much they hate Python (though they've never used it) because of its semantic white space.

> I don't understand why the python crowd refuse to acknowledge that having significant whitespace does cause some issues and the benefits are completely subjective.

All language decisions are trade-offs that come with some downside. I wrote Perl for 4 years, and I would still get tripped up by its break/continue syntax (next/last) on occasion since I learned to program in C/C++.

I currently am working heavily in both JavaScript and Python, and I don't have any indentation issues swapping between the two languages (probably the issue I come across the most of switching between under_scores and camelCase for names). I could probably count on one hand the number of times I've had an indentation error in Python.

> Sure unit tests will catch the error but in most other languages the error wouldn't have been introduced in the first place.

But this is essentially the same argument for static-typing over dynamic-typing, but that doesn't get the same amount of flack as white space in Python.

[Goladus]

I'm not making a mountain out of a molehill but I don't understand why the python crowd refuse to acknowledge that having significant whitespace does cause some issues and the benefits are completely subjective.

Here's what you wrote:

That's one of the big reason Python rubs me the wrong way: white space is semantic.

Defending python against a vague accusation like that is most certainly not "refusing to acknowledge that having significant whitespace does cause some issues"

that said, the benefits are not completely subjective. Whether you prefer the benefits or not is somewhat subjective, but the benefits can be clearly described. Specifically: you don't need braces or begin-end tags for code blocks. Correct code will always be indented based on the same concrete rules. Code can be moved from one block to another just by changing the indentation. Those are objective, not subjective traits.

[bjourne]

Indeed that is a problem when you are copy-pasting huge blocks of code. In deeply nested code it can be difficult to determine whether the nesting should be say 28 or 32 spaces. In practice, most people shy away from writing such code because to many levels of nesting is hard to follow. People also prefer to write atomic 5-15 line functions in which keeping track of the nesting levels is trivial.

Many C# and Java-heads complain that Python lacks support for auto-completion. Which is true, the language makes it so you can't have as sophisticated auto-completion as is available for the aforementioned languages in Visual Studio and Eclipse. But it's not so bad because Python developers are trained to prefer shorter names instead of OverlyLongJavaNames such as "getattrs" instead of "GetAllAttributes".

Btw have you noticed that on this site, the only thing that indicates how the comment threads are structured is how the individual comments are indented?

[Aloisius]

Many C# and Java-heads complain that Python lacks support for auto-completion. Which is true

Isn't that an IDE issue and not a language issue? I have no problem with the auto-completion in ipython for instance, though even ipython notebook is only useful for writing simple amounts of code. PyDev though works well too for larger projects albeit a bit sluggishly.

[bjourne]

No, Pythons dynamicness means it is in general impossible to find all available completions:

    m = type('', (), {})()
    setattr(m, 'foo', 123)
    m.f<tab>

Without actually running the code (which is unsafe), no editor could at that point figure out what the completion should be.

[dded]

If you're an Emacs user, have you tried Esc-/ (or M-/) for autocompletion? Note that this works in any mode, not just Python mode.

[klibertp]

I think all the modes for python in Emacs implement dedent and indent functions which behave nicely. I hacked one of them to leave selection active after the operation and now - it's still more than one command - I do C-y for paste, C-x C-x to select what was pasted and C-M-> or C-M-< to adjust indent.

On the other hand it's almost impossible to make a mistake with indentation with python-mode (and similar, I'm using all-in-one-plus-your-cat elpy package) when writing code - the enter key indents automatically (instead of having to press tab additionally) and it indents one level more after statements which need it. And backspace removes one level of indentation. I can't remember if I ever had a problem with indentation in Python in Emacs; although I know I had some with CoffeeScript.

So in short - it's all an editor support issue and some relatively trivial rules give you an experience as streamlined as in langs without significant whitespace.

Also, I'm a lisper so - paredit. Knowing about it and using it makes you realize how broken every other syntax is and how hard it is to edit ;)

(Replying just because of Emacs, the rest is uninteresting anyway - in my experience once you cross the border of 5-8 known langs you can easily accommodate to any syntax)

[agumonkey]

Lazy me never bothered to use proper indent/dedent function, since TAB will cycle through indentation levels.. but I'm happy I read your comment since cycling isn't efficient.

ps: although it seems, vanilla python mode binds them to 'C-c >' and 'C-c <'

Just like monads, sexps have that curse when you get how paredit or alikes work, you just can't explain how awesome it is to non lispers.

[hharrison]

Any good editor should be able to figure out the indents when pasting. I'm not an emacs user, but I'd be surprised if there wasn't a plugin with smart python pasting.

[simias]

My point is that it's not always possible for the editor to know what the indentation is supposed to be because it can't know what the code is supposed to do.

Suppose you have code like this:

    [...]
        if a:
            b
        c
    [...]

And then you paste some snippet you got from somewhere else between b and c:

    [...]
        if a:
            b
    pasted_snippet
        c
    [...]

The editor cannot know how to indent that properly. It's not a problem in most other languages.

Again, I'm not trying to say it's a deal breaker and Python is useless as a result, I just think it's a small mistake in the design of the language. It's like non-breaking switch/case in C, it doesn't make the language unusable but it is an annoyance.

[pyre]

In that example, a good editor should indent pasted_snippet at least to the first indent level. If you wanted it to be part of the if statement then you could just select the pasted block (both Vim and Emacs should be able to do this with a single command) and indent it by one more.

Python's use of semantic white space is more a function of it's inheritance than anything. It's based off of ABC[1].

[1] http://en.wikipedia.org/wiki/ABC_%28programming_language%29

[Goladus]

The editor cannot know how to indent that properly. It's not a problem in most other languages.

It will have a pretty good idea. If you paste the snippet, then hit 'tab', odds are high that a good editor (I use emacs python-mode) will Do The Right Thing on the first try, although sometimes you'll have to hit tab again or backspace a couple of times to get the right indent level.

Occasionally I need to use a keyboard macro to fix the indent after a paste, but this is very easy to do and doesn't happen to often, really. I'm sure by now with python's popularity there are more advanced indentation management tools but I still just use emacs keyboard macros.

It's a very small price to pay for the huge benefits of semantic whitespace.

Generally the worst case scenario for copy/paste is that I'm using emacs in a terminal window and I forget to switch to fundamental-mode before pasting. Because the terminal is handling the paste, not emacs, python-mode treats it all as if it had been entered one line at a time and auto-indents everything after a colon, then pasting in lines that already have indentation and the result is a complete mess. (but then I just undo it all and re-paste it the right way) GUI emacs doesn't have this problem.

The worst case scenario I can think of for semantic whitespace (outside of copy/paste) is accidentally changing indent level of a piece of code without realizing it and a syntax error doesn't result, meaning there's now a logic flaw in your program you don't know about. Python is more susceptible to that than sort of regression error than most languages. That said, usually that sort of mistake WILL cause a syntax error and be easily fixed.