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

Why do some people feel like meaningful indentation is a deal-breaker with Python? It makes for readable code even in curly brace languages like JS, Java, and C. In fact, I found the first curly brace example with the odd indentation jarring. Being able to quickly scan a block of code and get a sense for what belongs to which block is incredibly valuable.


In my experience the people that complain about it most are those who just like to slop things together and not bother with even the most cursory attention to detail. For people with that attitude having to worry about details like white space no matter how trivial "gets in their way".


while i concur, there is one shining example where this is a problem: fixing someone else's code where a bug has been introduced due to mistaken indentation.

last week i fixed a bug where a mistake in indentation (maybe a cut and paste in a refactor?) caused something to be done once but not the correct number of times (once for every iteration). took a few minutes to figure out where to look, but it took a few minutes more to figure out what was intended and what the bug ultimately was (the disconnect between what you meant and what you did). while this is a small 2 line example, for larger code blocks this is a serious problem.

i'm not advocating for braces, but they have a helping hand in spotting these sorts of bugs.

that said i often dislike it when people dismiss python just on the whitespace complaint alone.


I've committed plenty of indentation bugs in Python.

But I've also committed bugs due to putting something on the wrong side of a closing brace.


I usually run other people's code through a linter if I don't like their coding style and have to read it. It saves a lot of pain later.


Please don't call manual copy-paste code changes refactorings. Here is the definition of refactoring :

> Typically, refactoring applies a series of standardised basic micro-refactorings, each of which is (usually) a tiny change in a computer program's source code that either preserves the behaviour of the software, or at least does not modify its conformance to functional requirements. Many development environments provide automated support for performing the mechanical aspects of these basic refactorings.

If you attempt to do computer's work for them, you're going to screw up. I screw up manual refactorings in Java too (e.g. misspelling variable names, misspelling one of the gazillion xml file declarations), and much more than in Python. Don't do manual refactoring.

The real flaw is that the architecture of python makes automated refactoring impossible. This is not due to the indentation sensitivity of Python.


Indentation rather than braces is probably the main thing that keeps me using Python over other languages. This project feels like a massive downgrade.

Would be very interested in projects that remove braces from other languages, though!


Something I like about Go is that there's a specified way to write your Go code, and the binaries are distributed with a tool to automatically format your Go code to the specification.

So, while you can write messy, unindented code, if you run gofmt over it, it'll look like everyone else's code (but probably still messy, because if you can't be bothered to indent your code, why would you be bothered to write clean code?).


I've had 20 years of dealing with C style parentheses and I've learned to parse it visually at a glance. I can't do the same with languages which use significant white space instead.

I imagine I could train myself to do so, but there is a cost involved.


I suspect if you were presented with a piece of code where the indentation and the braces disagreed, you would believe the indentation. Yes, it's easy to parse at a glance if it is correct, and the indentation agrees with it. If it doesn't, good luck seeing the error.

This is one of the good things about significant indentation: the human and the computer are reading the same signals.


I prefer not to be forced to use correct indentation. I do so as a matter of course. And on the odd occasion I have some reason to use odd indentation, I want to be able to do that too. I like to write my code according to my own judgement. I don't feel that indentation ought to be part of a language, just part of the code.

That said, I do sometimes write in Python and I have nothing against the language. This isn't meant to be an attack on Python.

Edit: also, the indentation in the first example is obviously just a means of illustrating that whitespace is non-significant with this project. I don't think they're suggesting code ought to be written without correct indentation.


> Edit: also, the indentation in the first example is obviously just a means of illustrating that whitespace is non-significant with this project. I don't think they're suggesting code ought to be written without correct indentation.

Does anyone anywhere have a realistic example of Python's indentation system being a hindrance? To me, the complaint always comes across as "I should hypothetically be able to do things that I would never actually do or endorse doing"

And it's not like there's no flexibility for weird corner cases. I mean, all of these things are already legal Python 3:

    for i in range(10): print(i)

    # although you wouldn't actually do this
    a = 3; b = 5; # a,b = 3,5

    # and you REALLY wouldn't do this but I couldn't help coopting their example

    if foo == "bar": _=(
        print("indenation"),
     print("doesn't"),
           print("matter!")
     )


In my experience writing python professionally (a while back), it was usually people who wrote very long methods with uneven nesting and single returns who had this complaint.

Guard statements and low cyclomatic complexity are important in all languages, but doubly so in python.


Why do some people find that braces are a deal-breaker? I couldn't care less that python doesn't have them, i.e. its not a 'feature' at all for me. I much prefer having them.




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

Search: