Hacker News Reader

Comment by riskable | Hacker News Reader

I asked a "C all the things!" developer a while back why he hated Python's enforced indentation and in a whole lot of words he basically said that it makes it difficult to visually track scope when you have long chains of conditionals.

The standard Python developer response to that is, "Aha! You like braces because they enable your bad programming practices!"

However, I found the best way to illustrate that point is this: I asked him, "If you're never allowed to use a text editor/IDE that highlights braces or the space between them ever again would you still prefer braces to indentation?"

I had to re-explain this concept several times but eventually I think he understood my point at least a little bit...

"Aha! You're using spaces because Python lacks decent development tools! In fact, because there's no static typing you can't even make a decent IDE for Python! Spaces are a crutch!"

Sigh.

View on HN

> * I asked him, "If you're never allowed to use a text editor/IDE that highlights braces or the space between them ever again would you still prefer braces to indentation?"*

Being visually impaired and also having coded since before syntax-highlighting editors became standard, yes. A brace character is something that's easy to visually perceive; whitespace isn't.

Haven't indent guides been around since forever? And generally if you can't tell what indent it's wrong, it probably needs refactored anyways.

It's definitely an opinion your allowed to have, though not using the language over it would be rather draconian.

Literally anything other than spaces that allowed easier linting, less "wait am I doing it right" regarding multi-line statements, etc.

If that is a keyword, or brackets, or whatever, I would prefer that. You can't minify or easily lint python. And you can't easily tell if there are mixed indent methods (tabs/spaces) and IDEs struggle with it vs. a simple bracket structure.

(This is a rare repost within a thread. I'm punching that card for 2018. Whitespace significance is my #1 issue with Python. I love the language, hate this feature.)

What linting is difficult in Python?

I find that the linting available in Python is better than that in c++, though c++ has better auto complete.

Minification of most of Python is possible, although shouldn't be considered of any value since it's not passed over the wire to a user.

I hate meaningfull identation because the tools I end up using suck at maintaining it. I end up bugfixing on customer systems, sometimes on systems used by coworkers. There is no editor with consitent tab vs. spaces or tab width settings. I had editors clear two indents at once, fail to correctly line up new indents more often than not. I will accept whitespace as sane block scoping method the moment every text editor follows the same settings out of the box with the ability to customize the settings removed.

>There is no editor with consitent tab vs. spaces or tab width settings.

This is just plain false. PyCharm does, and I am sure there are others.

While I have PyCharm on my dev. system the chance that I can use it while I am debugging or extending a script on a customers system is zero, sometimes there is kwrite, sometimes it is gedit and if it is headless I may get vim. So consistency is guaranteed to be non existent.

>"If you're never allowed to use a text editor/IDE that highlights braces or the space between them ever again would you still prefer braces to indentation?"

Yes. (Though that's hardly the worst thing about Python.)

Isn't deep nesting (hence deep indentation) a sign of code smell? Yeah, you might end up shuffling the logic into a new file or a function that makes the file much longer, but I've noticed when doing that kind of refactoring it forces you to clean up the scoping quite a bit so there's less state to keep track of.

It depends on your definition of "deep".

Imagine an if, inside of a foreach, inside of a function definition, inside of a class. This is not terrible code, it's perfectly reasonable.

Now you're indented four levels in. Now combine this with some rather unreasonable and outdated assumptions that PEP8 (automatically enforced in many shops and OSS projects) has, like pretending that people are still on glass terminals and that anything longer than 79 characters is a problem. It also insists on four-space tabs, so this very simple construct has eaten 20% of your line budget.

..not to mention how it makes your code harder to read. I also share the author's concern about how you're less able to separate your debug code from your actual code.

Four-space indent is very common in other languages too. I don't see why this choice should be argued over for Python specifically. The 80 char limit is also very common.

I too used to leave debug-code purposefully unindented. There are other ways to handle that and the loss is negligible to me considering there can't be misplaced braces in Python in return.

This is all subjective, so it's hard to make a water-tight argument either way (even if we were looking at a concrete code example)...that's one reason it's referred to as "smell" instead of a bad-practice. PEP-8 effectively starts with "A Foolish Consistency is the Hobgoblin of Little Minds." Every place I've worked used a modified version of PEP-8 for standards because it never worked out of the box. Like I was saying higher up, it's hard to tell who to blame. It is the reality of using that language, but the developers have made a strong effort to address it. I guess it's a lesson to future language designers or community managers?

More concretely, I often find deeply indented code more difficult to read. There are more local variables to keep track of and breaking it out into a function helps encapsulate and name what's going on. Even from your description I might look to see if I could use a generator to filter the loop instead of "for" and "if" which should be more clear, fewer indentations, and easier to optimize at runtime. I do find trying to break up long line onto multiple rather annoying because diffs are more difficult to read.

I've never really used whitespace to separate my debug and actual code...which probably speaks more to my background than anything else. I have tended to put a # at the beginning of the line when debugging and next to the comment when commenting. Linters don't seem to care for that, but the code is tidied up before it's committed.

Reply on news.ycombinator.com