Python: Myths about Indentation | Hacker News Reader

Python: Myths about Indentation

secnetix.de

56 pointsshawndumas73 comments

Python white space indentations adds some overhead when pasting code but overall I feel improves the code I write and the code I have to read. I think if it were possible to do multiline anonymous functions a lot of the feel of python would change and there would be a lot more function calling with nested anonymous blocks. I don't know if that would be an improvement or not, but I personally like my coworkers (and me) being forced to have a binding to the code they are writing in the block they are writing it in.

The adverse visceral reaction to white space (which I think is akin to the reaction to parens in lisp) appears to me to be people being unhappy with being "forced" to do something. These (for me) happen to be the same people who don't understand why the code they wrote in their personal (and ever fluid) style is no good to be added to our code base.

Interesting. Do you have references to support that code blocks are bad? They are popular most everywhere else? (-: It sounds like a cripple claiming they don't need their missing body part. :-)

The last paragraph is a straw man imho -- people have no business having a programming job if they can't use their team's code formatting rules. (If they work in a team of one, they still need to specify and follow coding/documentation standards.)

>Do you have references to support that code blocks are bad?

Which part of my post gave you the impression I was talking about anything other than direct personal experience? I made sure to be explicit about it.

I even say I don't know if they would be good or bad, but gave a reason why I like python disallowing them.

edit:

I take exception to the idea that my personal opinion needs to have a "reference" which would boil down to the personal opinion of another random person on the internet who supports my position authoring a blog post that looks "sciencey". Opinions on language features does not produce scientific studies.

>>I take exception to the idea that my personal opinion needs to have a "reference"

Oh, private musings instead of an argument? Less interesting. :-)

Argument? What was I arguing? In fact, what are you asking other than saying "my language is gooder than ur language!" In fact you haven't said that because you don't want to defend a position in a mythical argument I was putting forward. So instead you asked for a reference to an assertion I did not even make.

I said I like that my coworkers need local bindings to code they pass. You asked for a reference.

Well here it is! Some guy on the internet saying why python's lack of multiline anonymous functions is so good you should not only change coding styles but adapt his language over your language because his is obviously proven superior in every way, scientifically.[1]

[1]http://news.ycombinator.com/item?id=3057283

Yes, ruby blocks are useful. Yes, lambdas let lisps do cool things. Python makes you name your blocks. It's a horror show.

And to your straw man issue. Yes, we actually just terminate everyone on the spot who tries to commit code that doesn't follow pep8 to the letter. Even when it doesn't make sense for a line that isn't nicely split at 80 chars.

And by terminate, I mean execute.

-------

It's like any commentary on a language must be part of some epic language-war.

>>Argument? What was I arguing?

I read it as a possibly interesting new claim about programming languages.

If you just wrote without making/arguing a position, sorry for commenting. And reading.

Edit: That anonymous funs might not be good is totally new to me. I've never seen anything about it, but was willing to read. I hope you at least had fun flaming people... (z0r -- I didn't see a discussion in the article.)

If you had read the original post, you would have nothing to apologize for.

Python made the decision about blocks nearly two decades ago (1993). Why you expect a cited dissertation crammed into a comment on a 20 year old decision and then how you managed to extrapolate my post to "an interesting new claim about programming languages." is really mind boggling.

Do you just expect to be spoon fed information? Put some thought into your next comment before you demand something of another person when you aren't willing to put any effort in yourself.

> overhead when pasting code

No sure I get what you mean. I pasted a lot of code in PHP and Python, and in both case you have to select the pasted block and adjust left or right according to the change of depth level.

> people being unhappy with being "forced" to [indent]

Well, then why the Hell would these people be happy to be forced to write { and } around their blocks?

For me, there is one little annoyance with indent as syntax in Python, it is that it is harder for my editor (Vim) to let me jump from def to the end of the function, and the reverse. (Or there is a conf, a plugin I missed? I know about indent folding, but I just want % to behave like if I had curlies.)

>I pasted a lot of code in PHP and Python, and in both case you have to select the pasted block and adjust left or right according to the change of depth level.

Yes, you readjust the PHP for aesthetics. Not for correctness of execution.

In vim, if I recall(emacs for a while now), =G auto formats bracketed code without issue. Pasting code, deleting enclosing block, adding an enclosing block, or highlighting a mismatched bracket (when formatting goes horribly wrong) can be handled automatically.

> Yes, you readjust the PHP for aesthetics

Here we differ. A code uncorrectly indented is wrong for me, and must be corrected right now. I don't care at all if it runs or not.

    if user_set_delete:
        logger.info("User set flag to delete file")
    delete_file()

    if($user_set_delete===True){
        log("User set flag to delete file");
    delete_file();
    }

"Correct" and "looks good" can have very different consequences. Acting like proper indentation for looks is on the same level as proper indentation for execution is ignoring the real dangers of improperly indented python.

I know copying that php block will not change the execution, no matter how it is formatted vs copying python where I need to guarantee I've got it right. Hence "some overhead".

Actually

  if user_set.delete:
      logger.info("User set flag to delete file")
  delete_file()

Becomes:

  if ($user_set_delete==True){
      log("user set flag to delete file")
  }

  delete_file();

That was the point, I think.

The point being that when the indentation gets screwed up via the copy/pasting, the if changes the meaning of the code vs just changing the aesthetics.

[[ and ]] will jump to the start of the previous and next block, respectively. This gets you most of the way there. If you want true % movement for Python, look no further than:

http://www.vim.org/scripts/script.php?script_id=386

But really the plugin you should get and master is EasyMotion. Like vim in general, using it is going to feel painful for the first day or so. Between that plugin and auto-folding, I've never needed to use another movement command again.

One nice thing about significant indentation is that it forces new programmers to learn how to indent their code properly. I'm taking an Intro to Java course now (in retrospect, I should have tried to place out), and most of the students in the class have absolutely terrible indentation.

The only major downside of significant indentation is that it makes it impossible to define multi-line anonymous functions in a clean way.

I totally agree with you on indentation. I started with PHP and didn't bother indenting at all for a long time, then when I did it was only a single space. I tried three spaces for a while in an AP CS course in high school (I also tried and hated Python for a weekend during that first semester), then toward the end of that year I learned Python more seriously and fell in love. I still only indent two spaces though, my One True Way. =P

I think part of my initial dislike for Python was manually typing nested indentation, even with one space the level for class->def->for->if can get annoying to type. I used to use EditPad Lite that didn't have auto-indent. Everything got better once I learned vim.

Regarding multi-line lambdas in Python, you can do it more or less but like you said it's not clean and can be dangerous.

    a = [1]
    blah = lambda x: eval(compile('''
    print x
    a.append(x)
    ''', '', 'exec'))

Python's lambdas aren't functions, they're single expressions, so I don't think that the multi-line problem is significant.

I'm not convinced that multi-statement anonymous functions are a good idea.

They can make for pretty statements in Ruby. But my question is then...why can't you do it in python just like ruby

def go : this.some_other_method : here_is_my_block

> multi-line anonymous functions

This is maybe a bit far from the topic, but I would like to know why there is such a need for anonymous functions in Python.

I understand very well the need for stateless functions (functions that do not change anything else than their return value, have no side effect, except maybe logging), and I understood it was a piece of functional programming.

In Javascript, with silent overwriting of functions and without modules, it is obviously very bad to pollute the only namespace with function names that can clash with each other, but in Python, you are or should be always inside a relatively small scope, and there you can def _my_temp_func() without any problems, no?

Moreover, as it is lame to use _temp as function name, it forces you to formulate a meaningful function name, which is good pratice, especially for your lectorate, right?

Or am I missing something?

I don't know python, so I don't know if anonymous functions have been crippled there, but in other languages anonymous functions are used to do things such as create closures (not stateless).

For example, in scheme:

  > (define (foo x) (lambda (y) (+ x y)))
  > (define bar (foo 10))
  > (bar 5)
  15

This sort of thing is of course immensely useful.

You can do the same in Python, with named functions or lambdas:

  >>> def foo(x):
  ...   def add(y):
  ...     return x + y
  ...   return add
  ...
  >>> bar = foo(10)
  >>> bar(5)
  15

And it takes twice the token count and lowered readability for no gain whatsoever.

No gain at all? How do you figure?

Twice the token count? How did you get that?

foo = lambda x: lambda y: x + y

bar = foo(10)

This is perfectly correct Python code too if you prefer. The only real thing with Python's lambdas is that, because Python makes a distinction between statements and expressions, you can't easily do things like use temporary variables inside a lambda, but cases like that are rare and are typically more readable with a separate standalone function definition anyway.

lambdas can be really nice for use with python's more functional builtins, like filter, map, and sort. As an example, suppose you have a list like this:

  x = [{1: 'b', 2: 'a'}, {1:'a', 2:'b'}]

You want to sort it on the value at the "2" key. You could write a dummy function:

  def extract_2(dct):
    return dct[2]
  x.sort(key=extract_2)

Or, you could just use a quick lambda:

  x.sort(key=lambda dct: dct[2])

The latter is more terse, and to a functional programmer, more clear (YMMV, of course). Lambda is just syntactic sugar in python; it's not necessary, and a lot of places where a functional programmer uses it in python make more sense as list comprehensions, but I think it's a nice thing to have.

EDIT:

I think the biggest reason I prefer the lambda approach to the named-function approach is that I don't like seeing one-off functions defined first and then seeing them used later. If python could do this:

  x.sort(key=extract_2)
  def extract_2(dct):
    return dct[2]

or even somehow support ruby-style blocks, it wouldn't be so ugly to my eye. Python lets functions call functions that are defined below them at the module level, but not at the function level, so the above isn't valid in the scope of a function.

> This is maybe a bit far from the topic, but I would like to know why there is such a need for anonymous functions in Python.

Building new control structures in-language, without having to hack the interpreter, and without the result looking like somebody has puked all over your screen. First-class functions are under-used in Python because they're syntactically and semantically heavy. With full anonymous functions, the `with` statement would not have been needed, it could have been handled through a higher-order function, akin to Haskell's `bracket`[0]

> In Javascript, with silent overwriting of functions and without modules, it is obviously very bad to pollute the only namespace with function names that can clash with each other

Namespace pollution is completely irrelevant (it's very easy to handle it in Javascript via the namespace pattern).

> Moreover, as it is lame to use _temp as function name, it forces you to formulate a meaningful function name, which is good pratice, especially for your lectorate, right?

If it is, why can I put name-less blocks of code in `for`, `if`, `while` and `with` bodies?

Not all code blocks need a name. Those that do will be given one.

[0] http://hackage.haskell.org/packages/archive/base/latest/doc/...

In fact, Haskell style frowns on using too many lambdas. It's generally felt that adding named functions is better for debugging and readability, the same as in python. So with the bracket function, for example, it's still considered better practice to pass named functions to it.

> In fact, Haskell style frowns on using too many lambdas. It's generally felt that adding named functions is better for debugging and readability, the same as in python

That's really besides my point. And last time I checked, Haskell's `if` and `case` expressions did not take functions, they took anonymous expressions.

> So with the bracket function, for example, it's still considered better practice to pass named functions to it.

To pass a named function as third argument to bracket?

This is the main point:

"So the conclusion is: Python forces you to use indentation that you would have used anyway, unless you wanted to obfuscate the structure of the program."

You were going to use consistent indentation anyway, right?

It seems to me all the resistance from people who don't like Python's meaningful indentation is from people who haven't coded in Python. It seemed weird to me at first, too, but really, it takes about an hour of actually using code to think, "Hey, this just lets me get rid of all the ugly brackets, and you don't lose anything by having to write it this way!" I don't even think you have to love Python as a whole to get the fact that this part of it is simple and elegant.

I can attest to this being one of the people who resisted until I actually used the language. Now I absolutely can't stand languages without significant indentation. "why is this retarded language forcing me to manually end blocks when it's bloody obvious from indentation!!!"

Python's indentation rules as specced originally are considered too loose by most Python programmers, hence PEP8 -- specifying spaces only, and a host of readability rules.

Consider that the competing scripting language at launch was Perl.

Now consider the benefit to a large team of well formatted easy to read code; Python's whitespace and indentation rules are there to enhance maintanability and readability, and they generally work.

As the article shows, you CAN make python look worse, but you shouldn't.

Incidentally, languages like Google Go take this one farther and embed deterministic formatting as a part of the language toolkit. This is brilliant. I would like to see such a thing incorporated into Python as well.. (Where's my backlist of to-do items?)

I'm an avid python user and a big problem I have is that you can't finish a line with '.' and continue on the next line. For instance:

  some_object.
    do_something(..).
    do_something_else(..).

Doesn't work. It needs to be written:

  some_object.\
    do_something().\
    do_something_else()

  some_object\
    .do_something()\
    .do_something_else()

It's ok to write \ a couple of time, but I feel like it makes chain-able functional methods really ugly to use because of that.

You don't need to escape line endings within parens:

  (someobject
     .do_something()
     .do_something())

Yeah. That's the hack I use, but it makes it a bit no pythonic.

From what I gather, the Pythonic way to write that would be:

  some_object.do_something().do_something()\
    .do_something().last_thing()

Basically, go to the end of the line and wrap with an indent. That's the way that I see most function calls with a long list of arguments in Python. In Perl, you might see something like:

   GetOptions(
     'h|help' => \my $help
   );

Whereas in Python you would see:

  parser.add_option('-h','--help',meta="HELP",target="HELP",
      help="Print help message",action="store_true",default=False)

Question: why don't pythonistas use tabs instead of spaces for indentation? To my knowledge pretty much every editor can be customized to display tabs in whatever length users want e.g. 2 spaces, 4 spaces, etc... imo it's a lot easier than dealing with different sets of code with a varying number of spaces for indentation.

tabs are interpreted as exactly 8 spaces, and oftentimes people set editors to use less than 8 spaces

Why is that a problem though? If you consistently always use tabs for indentation, this interpretation does not matter.

Why does it matter to you if people set their editors that way? What is your point here?

Some people write assuming that 8 spaces and tabs are interchangeable. I can change my habits but cant change others. And in those cases, I have to set my tab width to 8 spaces to read it properly. I'm not condoning it -- but you have to realize that oftentimes we have to interact with others' code

The standard indentation is 4 spaces, and people often have their tabwidth set to 4 spaces. Sometimes tabbed code (often older code, before spaces were really standard), end up with mixed tabs and spaces. The logic of the code then reads completely differently depending on your editor settings.

I'm not advocating people mix tabs and spaces, I'm advocating that people always use tabs so that others can display it as they wish.

I think most people would rather use spaces for their own sanity. Most people would prefer not to bother adjusting tabwidths, ever. So the capability to adjust the display of code to individual's liking would be largely unappreciated.

In other words, forcing everyone to use tab-characters for spacing would be a burden on the majority for the benefit of a tiny minority.

The majority has to change their editor's settings to insert four spaces instead of a tabulation, anyway.

Well, unless you're just reading code.

I suspect most python developers get the "insert four spaces per tab" for free with whatever IDE they use.

There's no drawback if you're working alone. The rest of the community however, decided that spaces are the standard. Yes it's somewhat arbitrary (golang picked tabs for instance), but if you don't want to conform to the community coding standards, it only brings hardship upon yourself.

A lot of python is convention based, and you can break all the rules you want and still have valid code, but no one else will want to use or maintain it.

If you use tabs everywhere, your code alignment will be all wrong:

  if x:
  ----some_long_func_name(...,
  ----                    blah...

Note that ---- is indentation and the spaces need to be spaces. If you use tabs for all of this, it will come out misaligned.

You could say -- then why not use tabs for the indent part, and spaces for the alignment part? Because virtually no editors support doing this automatically (and doing this manually is not practical). The few editors that do support automating this, don't make it discoverable (let alone a default).

What you end up with is a horrible mixture of tabs and spaces, or if you use tabs only, then code that does not align right.

Using tabs simply does not work in practice. Spaces may have the (supposed) disadvantage of a fixed indentation size, but they really are the only way to make indented code work across different editors. And this is not an optional thing, therefore tabs should be banned, completely.

Technically that's incorrect. A parameter list has an implicit line continuation so the 4 spaces aren't necessary.

    if x:
    ----some_long_func_name(...,
                            blah...)
    ----fn2(x)
    else:
    ----fn3()

However, I do agree that using tabs in python quickly becomes an enormous headache.

My point was not that the code becomes incorrect -- but that the point of indentation is to make code readable, and it is lost when using tabs because the only correct use of tabs for indentation is not well supported by editors in practice.

Vim very easily allows me to use tabs for indentation and spaces for alignment...

"Using tabs simply does not work in practice."

Outside of the python community, "tabs for indentation, space for alignment" is quite common. Many people use it in practice, to say that it simply doesn't work is ignoring reality.

Vim does not do this by default, you have to enable it explicitly.

And then, when others edit the code -- the use some wrong mixture of tabs and spaces.

What I said is that it won't work in practice in a multi-editor environment. If everyone has a uniformly configured vim, it may work -- but no work environment I've seen ever had that.

EDIT: Can you name a single example project source I can look at that correctly uses tabs for indentation only?

I've never seen it work, it always deteriorates into a mess in my experience. Also, do you ever work with people who use Eclipse, Visual Studio, Notepad++, and various non-vim editors?

But the fact that python does this is a flaw. There would be no problems if it forced you to use the same spacing characters in a block instead of just the same spacing count.

For example.

  if foo:
  [tab]bar #valid

  if foo:
      bar #valid

  if foo:
      if baz:
          bar #valid

  if foo:
      if baz:
  [tab]bar #invalid  Your four spaces disappeared but it wasn't a DEDENT.

  if foo:
      if baz:
      [tab]bar #This can be valid, I guess.  Doesn't harm anyone.

Once you don't allow people to interchange tabs and spaces it's perfectly safe to set tab width to any amount.

Exactly. I strongly dislike the way indentation is assumed to be done with x spaces. I quite like my indents of size 1 tab, and would hope the lexer differentiates between <tab><3 space><tab> and <tab><tab><3 space>, since I certainly do.

The article claims tabs are more likely to be shredded than spaces, but I didn't find that to be true. Half the tools on the Web are going to irreparably shred Python code no matter which you use. I still think Ruby is displacing it largely because it's actually possible to talk about Ruby code without ridiculous workarounds like pastebins.

>The article claims tabs are more likely to be shredded than spaces, but I didn't find that to be true.

def x():<enter>

<tab>"Oh no I'm on the reply button!"<Shift+Tab><space><space><space><space>print "Much Better"

The problem isn't entering a tab character (I'd be pasting code from a real editor anyway). The problem is that whatever indentation you use, whether it's tabs or spaces, is destroyed by many common tools, and un-indented Python is ambiguous and can't be fixed without guesswork.

Tabs are more likely to be destroyed than spaces. Simply displaying a file in a character-based terminal shreds tabs. Spaces are fine.

It's true there are tools, especially on the web, that eliminate whitespace and if you rely on those tools using python is going to be a problem. But generally it's pretty obvious whether that's going to be an issue. Tab problems tend to sneak up when you least expect it.

At some point, people need to decide on a standard, which was eventually documented as pep8. Since whitespace is significant within the language, two groups using different conventions may run into problems inter-operating.

In older tabbed python code, I've seen numerous patches fail to run, because the patch had the wrong indentation scheme. Worse, were patches I've found that ran, but with subtle bugs, because the change in indentation modified the logic without runtime errors.

Because spaces allow for indentation and alignment in every editor under the sun.

Also, because tab is a pointless character and an outdated hack.

Which is an argument for mixing tabs and spaces. Which Python doesn't very well handle.

Because redefining tab width as something other than 8 is, quite frankly, a disaster.

The problem is, a "tab" does not advance by 8 spaces; it advances to the next column divisible by 8! Shockingly, most editor writers don't seem to realize this; this appears to be especially true in the Windows world (perhaps because they never used typewriters or ASCII terminals?)

The resultant code is only readable in an editor with the same settings; for a language like Python, the resultant code will, in fact, be semantically incorrect.

Some editors that are not broken (eg. emacs, vim), allow you to specify a desired indentation level, and then the editor constructs the correct combination of tabs and spaces (ideally just spaces, for Python) to indent the code to the correct depth.

This comes from someone who has to regularly recover code mangled by dozens of Windows "programmers" who edit code on so-called "Programmers" editors with alternate tab settings...

> why don't ... use tabs instead of spaces for indentation?

http://www.jwz.org/doc/tabs-vs-spaces.html

Myth: "You cannot safely mix tabs and spaces in Python."

In fact, you can mix 8 tabs with spaces in CPython (and do wacky stuff like

def f():

<tab><8 spaces>x=3

<4 spaces><tab><4 spaces>y=3

<8 spaces><tab>return x+y

You can, yes, but is it safe?

My understanding of the article is that you shouldn't do it, because it's liable to cause confusion -- it's not safe.

In Python 2, you can run tabnanny[1]. In Python 3, I do not believe that unambiguous tab mixing is allowed.

1: http://docs.python.org/library/tabnanny.html

> "You cannot safely mix tabs and spaces in Python."

You can mix spaces and tabs all you want as long as you are consistent. This is fine.

    if 0:
    <tab><sp><tab><sp>1
    <tab><sp><tab><sp>2

This is not, for any number of spaces.

    if 0:
    <tab>1
    <sp><sp><sp><sp><sp><sp><sp><sp>2

Technically, the parser converts one tab to 8 spaces (at least in the versions of python I'm familiar with), so your second statement is not quite true.

def foo(): <tab>print 'a' <sp><sp><sp><sp><sp><sp><sp><sp>print 'b'

compiles and runs properly in python 2.6.

I don't really have a problem with Python per se, but the one thing that bugs me is that the significance of indentation encourages the use of 4 or 8 space indents. I guess on one hand it's good because it would probably discourage heavy nesting, but seems like it would be a pain to paste on blogs and would require a lot more eye movement.

I guess you probably just get used to it, I'm just coming from the 2 space Ruby standard.

I will say that the person I know with the most visceral reaction to Python's indentation rules writes code like this:

  sub func { shift->func1(shift)->func2(@_) }
 
  sub things_with_attr { grep { $_[0]->is_attr_true($_) } $_[0]->things }

Only the function names have been obscured.

Reply on news.ycombinator.com