Quantcast
Viewing latest article 2
Browse Latest Browse All 3

Python indendation rocks (and sucks a little bit).

Andy Buckley wrote a blog about why Python indentation was bad. He has two arguments, and one example. Fortunately, he is mostly wrong. He is right about his first argument: Invisible syntax isn’t really a good idea. A really good example of invisible code was old to me by a friend in Sweden many years ago. There was a programming language, I’ve forgotten the name, where any characters where allowed in variable names. For a joke, people would insert the escape codes for colours in the variable names, so you would have a green variable, named red, and a red variable named red. Highly confusing. Then somebody figured out you could call the variable <escape to red><escape to red>red<escape back>. This would of course be completely indistinguishable from the other red red variable, and make the program incomprehensible.

Yes, invisible syntax is bad, and if you mix tabs and spaces in Python, the syntax indeed becomes invisible. Andy will without a doubt be happy to know that Python 3 will no longer allow it. Try it and you get “TabError: inconsistent use of tabs and spaces in indentation”. This news was greeted at PyCon this year with loud cheers. That means that with Python 3, the syntax is no longer invisible. You will see the difference in indentation, the indentation can no longer be ambiguous. Yes, you can still mix three spaces with two spaces and one space and ten spaces. But that doesn’t matter. Inconsistent indentation might be confusing, but no more so that inconsistent variable naming, and is no fault of the language.

The second reason from Andy is that you can’t use tools to fix the indentation. But this is in fact incorrect. If the indentation is broken, that is a syntactic error. It’s a bug. You can’t use tools to fix bugs, you need a programmer. His has an example of broken indentation and asks how it should be fixed. It’s this:

def myfunction(foo, bar):
    foo.boing()
   for i in bar.fizzle(foo):
      baz = i**2
    foo.wibble(baz)
    return foo, baz

Well, but with braces, that code would look like this (or similar, the indentation errors makes the code ambiguous, so there is alternative ways of misplacing the braces.):

def myfunction(foo, bar): {
    foo.boing()}
   {
   for i in bar.fizzle(foo): { {
      baz = i**2 }
    foo.wibble(baz)
    return foo, baz }
}

How would you correct that? Which braces are incorrect? There is an error in how the blocks are created, and you can’t fix that with a tool, no matter if the blocks are created with brackets or white space.

Andy’s real world example is that he needed to cooperate with somebody whose editor liked using a mix of tabs and three-space indents. First, delete that editor, or fix the configuration. Secondly, as long as the indentation in fact is correct, you can fix it. The confusion comes if you use an editor where you have said that tabs should be shown as equal to four spaces, and you mix tabs and spaces. Then you can get things that look like this:

def foo():
      for x in range(5):
    print x

And you go “wha?” Because that print line starts with a tab, which is expanded by python to eight spaces, but shown by your editor as four. And the line before contains six spaces. So, Python will interpret this correctly, your editor will not. However, if you look at the file with “less” it will look OK. These type of problems are fixable. You can use a script that replaces all tabs with spaces, correctly. Then the file will look OK. And if the indentation after this is a mix of two, five and umpteen spaces, this is also fixable by tools. In fact WingIDE, which I use, will complain on mixes of tabs and spaces and ask if they should be fixed. It will adapt the indentation to what is already going on in the file, so when I get a file written with three spaces as indentation (this has happened), this works just fine, but I can also tell it that no, it should in fact always be 4 (or 2 or 6 or 9) spaces as indentation, consistently, and it will re-indent the whole file.

So, yes, invisible syntax is bad. Yes, Python 2 has it. Python 3 does not. That you can’t fix programmer bugs with tools is nothing unique for Python. You can fix ugly indentation in Python, as long as the code actually runs.

There is however one actual problem with the indentation: There is no do-until loop. And this is because you can’t write:

do:
  blablablabl
until x

This is a pity, because I want a do until loop. An alternate syntax is possible:

until x:
   blablablablabal

But this apparently has been decided against, because it means that the test comes before the code, and the variables used in the test gets defined after the test, which apparently is frowned upon from a syntactic point of view. I don’t care. I still want an until x statement, but it seems I won’t get one. And this is the indentations fault, and the only real problem with Pythons indentation as I see it. But the benefits still are so many more and so much bigger that the drawbacks get dropped-kicked into PHP-land.


Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.

Viewing latest article 2
Browse Latest Browse All 3

Trending Articles