4 ms·

Python indentation: very nice explanation for the curious or skeptical

23 points by benhoyt 19y ago

dappelbaum 19y ago
mt
- eru 19y ago
  ?
  - lst 19y ago
    mt = me too (to me)
    - eru 19y ago
      Ah, thanks for enlightening me.
      - dappelbaum 19y ago
        thanks for the heads up, sorry for the mistake.
- dappelbaum 19y ago
  Hey I said I was sorry what is with the repeat downmoding? Karma police, jeez...
eru 19y ago
I never understood why some people are so adverse to python's indentation rules. But maybe that's because I was too young when I was introduced to python.
- Goladus 19y ago
  I think it's sort of presumed by the article, but there are a few things people worry about when they hear "significant whitespace" -They remember pain of trying to find an error in a code, data, or config file that had significant whitespace. Consider the 'tab-delimited' spreadsheet format, for example. If you manually edit a tab-delimited list of numbers, and accidentally leave a space somewhere, the number might be read as a string. -They've spent a lot of time dealing with HTML rendering, where whitespace gets mangled and cannot be trusted. -They're afraid they won't be able to make their code readable. -They're afraid that the whitespace rules will be complicated, requiring them to think constantly while adjusting to this newfangled way to delimit blocks.
  - ced 19y ago
    -They've used Fortran 77 which requires 6 whitespaces before a normal statement, 5 + any character for line continuations, and which truncates silently (as in, without warning) any line longer than 72 characters.
  - mojuba 19y ago
    Philosophically speaking, we live in a world where the number of spaces doesn't matter anymore (although it did matter in those pre-historic pre-Internet times). Spaces may be lost in HTML, in word processors or in an editor that accidentally wasn't tuned for Python. However neat and readable it is, just try to show your code, for example, on some minimalist web forum like this one. It's too bad you can't, isn't it? It is also true that Python has survived already, but I doubt this concept would leak to new languages. Upd: In other words, it's electronic typography that made the space character irrelevant.
    - eru 19y ago
      Source code is still nearly universally viewed in non-proportional fonts.
  - DocSavage 19y ago
    - They don't like the idea that cut & paste of code snippets will break the code due to significant indentations. Counter-arguments include (1) you should probably beautify the code anyway and check for issues while doing it, (2) code snippets should be in modules with smallish functions.
mdemare 19y ago
<snipped code example, what kind of mark-up is valid here anyway?> Anyway, I don't like the notation for programming, but I love it for HTML: http://haml.hamptoncatlin.com/ http://haml.hamptoncatlin.com/
ivankirigin 19y ago
My guess is that most people that don't like the indentation have never used it. It is notably more readable when looking at someone else's code, and makes wonderful use of whitespace. Now if only there were some formatting standard to get rid of some of that parens in Lisp without loss of power.
- Goladus 19y ago
  Funny thing... the other day I tried converting some Lisp to Python as a demonstration, and discovered that the number of parens you get to remove depends largely on the programming style you're using. Mostly, they just get shifted around or replaced with brackets (or braces), and you have to add a lot of commas. If you scan over http://norvig.com/python-lisp.html http://norvig.com/python-lisp.html, you'll see a lot of opportunities to remove parens; but in fact many of those are not semantically identical. In python, a block does not return a value. if a:f(x);else:g(y) If you wanted it to return a value, you'd have to rewrite 'if' as a function and say something like: myif(a, [(f, x)], [(g, y)]) If you wanted to evolve python towards Lisp without having to add parens, I'd make it so indented blocks are actually expressions and automatically return a value to the defining block. (Of course, the normal python way is to use "return" statements or side-effects, rather than writing an ad-hoc version of the lisp 'if')
  - andyn 19y ago
    Python 2.5 now lets you do: x = f(x) if a else g(y) f() and g() aren't evaluated till they're needed.
    - brlewis 19y ago
      That syntax looks like it's intended to communicate that f(x) is the normal result, and g(y) is exceptional. I wouldn't want to use it unless that's what I intended to communicate. It also looks like you would need to put parens around the "if" expression if you were to use it within a more complex expression, e.g 2 + (f(x) if a else g(y)) + 3
    - nostrademons 19y ago
davidw 19y ago
I had the chance to meet up with Guido at one of the Linux conferences in 1999, back before Python was all that popular. Very nice guy, but something I said then still stands true, in my opinion: The white space issue doesn't really matter. Except for a few specialized areas like template creation, where Python is just not a natural fit. That's one of the things I like about Rails - Ruby may not be the absolute perfect language for scripting web templates (maybe Tcl is?:-) but it's good enough, and it's useful without some of the weird hacks that the Python guys use to do templates.
- AF 19y ago
  I'm sure you know that the idea of using code in templates is controversial anyway. But I do like it, and Mako, imo, solves the issue with Python very well. % for row in rows: * Here is a row: ${row} % endfor http://www.makotemplates.org/ http://www.makotemplates.org/ That's kind of 'hackish', but not bad at all if you ask me. Compared to an ERB snippet it is about the same (though you'd probably use each and a block here in Ruby. <% for row in row %> * <%= row %> <% end %>

23 points by benhoyt 19y ago

eru 19y ago
?
- lst 19y ago
  mt = me too (to me)
  - eru 19y ago
    Ah, thanks for enlightening me.
    - dappelbaum 19y ago
      thanks for the heads up, sorry for the mistake.
dappelbaum 19y ago
Hey I said I was sorry what is with the repeat downmoding? Karma police, jeez...

eru 19y ago

I never understood why some people are so adverse to python's indentation rules. But maybe that's because I was too young when I was introduced to python.

Goladus 19y ago
I think it's sort of presumed by the article, but there are a few things people worry about when they hear "significant whitespace" -They remember pain of trying to find an error in a code, data, or config file that had significant whitespace. Consider the 'tab-delimited' spreadsheet format, for example. If you manually edit a tab-delimited list of numbers, and accidentally leave a space somewhere, the number might be read as a string. -They've spent a lot of time dealing with HTML rendering, where whitespace gets mangled and cannot be trusted. -They're afraid they won't be able to make their code readable. -They're afraid that the whitespace rules will be complicated, requiring them to think constantly while adjusting to this newfangled way to delimit blocks.
- ced 19y ago
  -They've used Fortran 77 which requires 6 whitespaces before a normal statement, 5 + any character for line continuations, and which truncates silently (as in, without warning) any line longer than 72 characters.
- mojuba 19y ago
  Philosophically speaking, we live in a world where the number of spaces doesn't matter anymore (although it did matter in those pre-historic pre-Internet times). Spaces may be lost in HTML, in word processors or in an editor that accidentally wasn't tuned for Python. However neat and readable it is, just try to show your code, for example, on some minimalist web forum like this one. It's too bad you can't, isn't it? It is also true that Python has survived already, but I doubt this concept would leak to new languages. Upd: In other words, it's electronic typography that made the space character irrelevant.
  - eru 19y ago
    Source code is still nearly universally viewed in non-proportional fonts.
- DocSavage 19y ago
  - They don't like the idea that cut & paste of code snippets will break the code due to significant indentations. Counter-arguments include (1) you should probably beautify the code anyway and check for issues while doing it, (2) code snippets should be in modules with smallish functions.

mdemare 19y ago

<snipped code example, what kind of mark-up is valid here anyway?> Anyway, I don't like the notation for programming, but I love it for HTML: http://haml.hamptoncatlin.com/ http://haml.hamptoncatlin.com/

ivankirigin 19y ago

My guess is that most people that don't like the indentation have never used it. It is notably more readable when looking at someone else's code, and makes wonderful use of whitespace. Now if only there were some formatting standard to get rid of some of that parens in Lisp without loss of power.

Goladus 19y ago
Funny thing... the other day I tried converting some Lisp to Python as a demonstration, and discovered that the number of parens you get to remove depends largely on the programming style you're using. Mostly, they just get shifted around or replaced with brackets (or braces), and you have to add a lot of commas. If you scan over http://norvig.com/python-lisp.html http://norvig.com/python-lisp.html, you'll see a lot of opportunities to remove parens; but in fact many of those are not semantically identical. In python, a block does not return a value. if a:f(x);else:g(y) If you wanted it to return a value, you'd have to rewrite 'if' as a function and say something like: myif(a, [(f, x)], [(g, y)]) If you wanted to evolve python towards Lisp without having to add parens, I'd make it so indented blocks are actually expressions and automatically return a value to the defining block. (Of course, the normal python way is to use "return" statements or side-effects, rather than writing an ad-hoc version of the lisp 'if')
- andyn 19y ago
  Python 2.5 now lets you do: x = f(x) if a else g(y) f() and g() aren't evaluated till they're needed.
  - brlewis 19y ago
    That syntax looks like it's intended to communicate that f(x) is the normal result, and g(y) is exceptional. I wouldn't want to use it unless that's what I intended to communicate. It also looks like you would need to put parens around the "if" expression if you were to use it within a more complex expression, e.g 2 + (f(x) if a else g(y)) + 3
  - nostrademons 19y ago

davidw 19y ago

I had the chance to meet up with Guido at one of the Linux conferences in 1999, back before Python was all that popular. Very nice guy, but something I said then still stands true, in my opinion: The white space issue doesn't really matter. Except for a few specialized areas like template creation, where Python is just not a natural fit. That's one of the things I like about Rails - Ruby may not be the absolute perfect language for scripting web templates (maybe Tcl is?:-) but it's good enough, and it's useful without some of the weird hacks that the Python guys use to do templates.

AF 19y ago
I'm sure you know that the idea of using code in templates is controversial anyway. But I do like it, and Mako, imo, solves the issue with Python very well. % for row in rows: * Here is a row: ${row} % endfor http://www.makotemplates.org/ http://www.makotemplates.org/ That's kind of 'hackish', but not bad at all if you ask me. Compared to an ERB snippet it is about the same (though you'd probably use each and a block here in Ruby. <% for row in row %> * <%= row %> <% end %>