5 ms·

I know that I use python because of how easy it is to code. I can focus wholly, totally on the logic of my code without ever worrying about if I misplaced a sem

I know that I use python because of how easy it is to code. I can focus wholly, totally on the logic of my code without ever worrying about if I misplaced a semi-colon or left out some weird punctuation. Python frees me to code and not worry about things that get in the way of coding. That's why it's eating other language's lunches, the freedom is almost intoxicating.

area51org 13y ago
It's ironic that you say that, given that if you don't get the whitespace correct, you'll have a syntax error. That's one of the big reason Python rubs me the wrong way: white space is semantic.
- pyre 13y ago
  Getting the indentation right should be the least of your worries if you have a good editor (and don't do something like mix spaces and tabs, which I think everyone is in general agreement with across all languages). When was the last time that you manually typed out 4 (or 2, or 8, etc) spaces to indent a line of code vs. just hitting tab and letting the editor handle inserting those spaces (or the editor automatically indenting when you hit enter on the previous line)? As an aside, all of the people that I've met in person that get red in the face over the idea of white space being semantic are the sort of people that write code like this: sub function1 { return map { $_[2]->do_something($_) } @{shift->(@_)[0]} } I'm sorry, but I can't get worked up about not being able to write code like that. Note: the above code is a reasonable approximation of actual code I encountered by an actual person that would get visibly upset about Python's semantic white space. P.S. The two '$_'s in the map block actually refer to two different variables, and this is one of the reasons I remember that bit of code. It makes no sense to mix usage like that because it becomes confusing.
  - frou_dh 13y ago
    > Getting the indentation right should be the least of your worries if you have a good editor (and don't do something like mix spaces and tabs, which I think everyone is in general agreement with across all languages). Nope. Tabs are for indentation and spaces are for alignment. It's precisely because of non-good (or maybe non-smart) editors that people can't be bothered acknowledging or practicing this distinction and end up using spaces for both.
    - pyre 13y ago
      I was mainly talking about mixing tabs and white space for indentation. Many people set their tabs equivalent to different numbers of whitespace, so when the whitespace and tabs mix, it becomes an issue if the previous developer had tabs set to 2 spaces, but you have them set to 4.
    - maxerickson 13y ago
      Conveniently, any editor that can properly deal with tabs will have an easy time dealing with semantic leading spaces.
    - deleted 13y ago
      [deleted]
  - __david__ 13y ago
    > The two '$_'s in the map block actually refer to two different variables Yeah, but that's Perl 101. Grabbing an element of array @a is $a[0], which is wholly different than plain $a. That's not really a style thing, it's a Perl thing, for better or for worse. > I'm sorry, but I can't get worked up about not being able to write code like that. Why? It looks more or less reasonable to me. Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters. @_ and $_[] are simply a fact of life when writing Perl. It's even a single expression which means you could probably write a similar one liner in python (since their wimpy "lambda" only does expressions)
    - pyre 13y ago
      > Yeah, but that's Perl 101. Grabbing an element of array @a is $a[0], which is wholly different than plain $a. > > That's not really a style thing, it's a Perl thing, for better or for worse. That code confused me after working in nothing but Perl for 4 years. It was confusing because I wasn't used to people having an array (@_ in this case) and a scalar ($_) named the same thing, and used in close approximation. The issue could have been avoided by (e.g.) setting $_[2] to a variable first, and would have made the code more readable. It's not "Perl 101" to write code that is intentionally obtuse. > Why? It looks more or less reasonable to me. Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters. @_ and $_[] are simply a fact of life when writing Perl. That code could be written in a way that was easier to read and maintain. For example, what is 'shift' intended to be? The only information we have is that it's supposed to be the first argument to function1. Edit: > Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters This was in a code base with a source filter to provide function parameters. That could have been written as: sub function1($arg1, $arg2, $arg3) { } in that code base, but the developer in question chose not to. Even without said source filter, you can still name the function parameters: sub function1 { my ($arg1, $arg2, $arg3) = @_; }
      - __david__ 13y ago
        > For example, what is 'shift' intended to be? "shift->method()" a very standard Perl idiom for OO code. If you presume the code was called via a blessed reference, then "shift" == "this".
  - gvb 13y ago
    You are being kind or your coworker isn't that bad - in your example the whitespace is consistent. My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels. Sloppily formatted code is Edward Bear code. All the bumping makes it hard to think about how it works (or, more often, why it doesn't work). "Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it." - http://www.gurteen.com/gurteen/gurteen.nsf/id/L001362/ http://www.gurteen.com/gurteen/gurteen.nsf/id/L001362/
    - pyre 13y ago
      > My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels. This is usually due to: 1) Lack of a consistent style guide. 2) Lack of style guide enforcement. 3) A language where white space doesn't matter. If you think about this critically though, these random indentation changes would either break all of the code (e.g. it wouldn't run, or would run but not work correctly) or it would make code maintenance a nightmare. Yet there are plenty of Python shops out there, and we don't hear horror stories of Python white space maintenance nightmares. Either the Python community is doing a good job of hiding these issues, or they really aren't issues in practice. Of the people I've talked to in-person about Python semantic white-space, the common threads are either: 1) It's different than what I'm used to. 2) It's cramping my style. My code is art, and restricting how I can structure my code is an affront to my very being.
      - jessaustin 13y ago
        I guess I'm in a third camp: 3) Python's semantic whitespace is so wonderful I'm baffled that most other programming languages don't have it. It's like they're coding with one eye shut: why not do this wonderful thing that makes everything easier?
        pyre 13y ago
  - simias 13y ago
    > Getting the indentation right should be the least of your worries if you have a good editor I never understood that. The whole problem for me is that the indentation being the only thing denoting blocks the editor can't know for sure how things should be indented, since it's not simply cosmetic. I haven't written a whole lot of Python but how do you even refactor python code? In C I can just copy paste a block of code from anywhere to anywhere (no matter the coding style in the source and destination file and the level of indentation) and then hit C-M-\ in emacs and have it reindent everything properly. In Python you have to make sure that everything is at the level of indentation it belongs to. If you refactor huge chunks of code it's easy to miss one fubar tab and have code subtly broken and introduce weird regressions. Also, regarding the OP and "focusing only on your code", I think we all feel that way about the language we're the most familiar with. For me that's C and I can't say I've had a "missing semicolon" compilation error in months of heavy use. Once you're used to the syntax it becomes automatic.
    - hharrison 13y ago
      Any good editor should be able to figure out the indents when pasting. I'm not an emacs user, but I'd be surprised if there wasn't a plugin with smart python pasting.
      - simias 13y ago
        My point is that it's not always possible for the editor to know what the indentation is supposed to be because it can't know what the code is supposed to do. Suppose you have code like this: [...] if a: b c [...] And then you paste some snippet you got from somewhere else between b and c: [...] if a: b pasted_snippet c [...] The editor cannot know how to indent that properly. It's not a problem in most other languages. Again, I'm not trying to say it's a deal breaker and Python is useless as a result, I just think it's a small mistake in the design of the language. It's like non-breaking switch/case in C, it doesn't make the language unusable but it is an annoyance.
        pyre 13y ago
  - mahyarm 13y ago
    The problem is larger multi-people projects. You need very strict editor/whitespace discipline, and you don't want to commit some sort of re-indent which touches every line of a file. That and the refactor issue is the main issue people have with the whitespace thing.
    - pyre 13y ago
      Which is why we have things like linters, pep8, and pre-commit hooks. :P
  - ufmace 13y ago
    It's easy enough if you have only one editor on one computer that you use with only one language. If you mix and match a half-dozen editors on multiple computers running different OSes coding in different languages, then it gets messier. Especially when all of the editors have different ways to set preferences for whether to use spaces or tabs, how much space per tab/indent, and whether those preferences are for this session, this language, or permanent. What, am I the only one that does that?
    - pyre 13y ago
      One of my pet peeves with Emacs is the way that it indents things (at least by default), so you won't find me using it. :-P
- drdeadringer 13y ago
  "white space is semantic" Is this not true for webpages and journalism?
  - frenchy 13y ago
    Semicolons are semantic in journalism too.
    - klibertp 13y ago
      As they are in Python: import os; import antigravity; # etc...
- Ensorceled 13y ago
  I used to think that way. But then I realized it forced all my co-workers to get their freakin' indenting correct.
- Arnor 13y ago
  Yeah, I hate when my language forces me to write pristine code...
- manish_gill 13y ago
  Eh, this argument is at least 10 years old now, isn't it? I don't even remember the last time I had a problem with whitespace in Python. Just use a decent editor (vim!) and you're golden. :)
- collyw 13y ago
  I disliked the whitespace thing at first, but after using it for a while I got used to it. Then when I had to go back to change some Perl code I realised the real beauty of it - you never get the problem of having unmatched braces when moving blocks of code around.
- hnriot 13y ago
  seriously? you should be properly indenting your code anyway, so it's not like python's making you do more than you should already.
- Goladus 13y ago
  It's ironic that you say that, given that if you don't get the whitespace correct, you'll have a syntax error. That's one of the big reason Python rubs me the wrong way: white space is semantic. Not to pile on but this is exactly backwards. The whitespace saves keystrokes and errors because it's giving a semantic meaning to something that programmers put in their code anyway. Now that I've actually written some code in ruby, I can't comprehend how rubyists aren't driven insane by the 'end' tokens. I'm sure this is a newbie mistake but on multiple occasions I've written something like this: def foo(x) if x > 5 puts x else puts 5 end foo(7) foo(3) Any experienced ruby programmers should see the error pretty quickly. But it LOOKS pretty good. Here is the error you get: test.rb:9: syntax error, unexpected $end, expecting kEND What's on line 9? That's just the end of the file. Nowhere near where the syntax error actually is. In this trivial example, tab-checking the indentation using my editor will reveal the error. But this is a trivial example. In more substantial code this technique is not nearly as effective. In erb templates its harder still. That never happened to me in python, even as a newbie. If I forget a colon I almost always know instantly because the editor will try to indent my code dramatically wrong. And if I inadvertently delete the colon at a later time without updating the indentation (this happens a lot) I get an instant syntax error that points me right at the line where the colon is missing. It's an error you can fix in your sleep. You don't forget end tokens because there are no end tokens to forget. The block ends when the indentation level decreases.
klrr 13y ago
So you are enabled to focus wholly since you are used to its syntax?
- GlennS 13y ago
  I really do think Python's convenience is more than just familiarity. I found it very quick to learn and easy to remember compared to other languages.
agumonkey 13y ago
Feels exactly the same about Lisp and other languages.
CmonDev 13y ago
Yeah, also who needs type checking when you can simply write dozens of unit tests!
qw 13y ago
I often forget ending for/while/if statements with a colon. http://markmail.org/message/ve7mwqxhci4pm6lw http://markmail.org/message/ve7mwqxhci4pm6lw In my opinion they should not be required because they cause more problems than they solve.
dkersten 13y ago
without ever worrying about if I misplaced a semi-colon or left out some weird punctuation I've seen enough code like [(foo[-1:self._bar:2]%(a,b),) for foo in quux] to not really believe that.
- Goladus 13y ago
  the parser is usually really good at spotting those errors and once they've been pointed out are trivial to correct.

area51org 13y ago

It's ironic that you say that, given that if you don't get the whitespace correct, you'll have a syntax error. That's one of the big reason Python rubs me the wrong way: white space is semantic.

pyre 13y ago
Getting the indentation right should be the least of your worries if you have a good editor (and don't do something like mix spaces and tabs, which I think everyone is in general agreement with across all languages). When was the last time that you manually typed out 4 (or 2, or 8, etc) spaces to indent a line of code vs. just hitting tab and letting the editor handle inserting those spaces (or the editor automatically indenting when you hit enter on the previous line)? As an aside, all of the people that I've met in person that get red in the face over the idea of white space being semantic are the sort of people that write code like this: sub function1 { return map { $_[2]->do_something($_) } @{shift->(@_)[0]} } I'm sorry, but I can't get worked up about not being able to write code like that. Note: the above code is a reasonable approximation of actual code I encountered by an actual person that would get visibly upset about Python's semantic white space. P.S. The two '$_'s in the map block actually refer to two different variables, and this is one of the reasons I remember that bit of code. It makes no sense to mix usage like that because it becomes confusing.
- frou_dh 13y ago
  > Getting the indentation right should be the least of your worries if you have a good editor (and don't do something like mix spaces and tabs, which I think everyone is in general agreement with across all languages). Nope. Tabs are for indentation and spaces are for alignment. It's precisely because of non-good (or maybe non-smart) editors that people can't be bothered acknowledging or practicing this distinction and end up using spaces for both.
  - pyre 13y ago
    I was mainly talking about mixing tabs and white space for indentation. Many people set their tabs equivalent to different numbers of whitespace, so when the whitespace and tabs mix, it becomes an issue if the previous developer had tabs set to 2 spaces, but you have them set to 4.
  - maxerickson 13y ago
    Conveniently, any editor that can properly deal with tabs will have an easy time dealing with semantic leading spaces.
  - deleted 13y ago
    [deleted]
- __david__ 13y ago
  > The two '$_'s in the map block actually refer to two different variables Yeah, but that's Perl 101. Grabbing an element of array @a is $a[0], which is wholly different than plain $a. That's not really a style thing, it's a Perl thing, for better or for worse. > I'm sorry, but I can't get worked up about not being able to write code like that. Why? It looks more or less reasonable to me. Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters. @_ and $_[] are simply a fact of life when writing Perl. It's even a single expression which means you could probably write a similar one liner in python (since their wimpy "lambda" only does expressions)
  - pyre 13y ago
    > Yeah, but that's Perl 101. Grabbing an element of array @a is $a[0], which is wholly different than plain $a. > > That's not really a style thing, it's a Perl thing, for better or for worse. That code confused me after working in nothing but Perl for 4 years. It was confusing because I wasn't used to people having an array (@_ in this case) and a scalar ($_) named the same thing, and used in close approximation. The issue could have been avoided by (e.g.) setting $_[2] to a variable first, and would have made the code more readable. It's not "Perl 101" to write code that is intentionally obtuse. > Why? It looks more or less reasonable to me. Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters. @_ and $_[] are simply a fact of life when writing Perl. That code could be written in a way that was easier to read and maintain. For example, what is 'shift' intended to be? The only information we have is that it's supposed to be the first argument to function1. Edit: > Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters This was in a code base with a source filter to provide function parameters. That could have been written as: sub function1($arg1, $arg2, $arg3) { } in that code base, but the developer in question chose not to. Even without said source filter, you can still name the function parameters: sub function1 { my ($arg1, $arg2, $arg3) = @_; }
    - __david__ 13y ago
      > For example, what is 'shift' intended to be? "shift->method()" a very standard Perl idiom for OO code. If you presume the code was called via a blessed reference, then "shift" == "this".
- gvb 13y ago
  You are being kind or your coworker isn't that bad - in your example the whitespace is consistent. My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels. Sloppily formatted code is Edward Bear code. All the bumping makes it hard to think about how it works (or, more often, why it doesn't work). "Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it." - http://www.gurteen.com/gurteen/gurteen.nsf/id/L001362/ http://www.gurteen.com/gurteen/gurteen.nsf/id/L001362/
  - pyre 13y ago
    > My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels. This is usually due to: 1) Lack of a consistent style guide. 2) Lack of style guide enforcement. 3) A language where white space doesn't matter. If you think about this critically though, these random indentation changes would either break all of the code (e.g. it wouldn't run, or would run but not work correctly) or it would make code maintenance a nightmare. Yet there are plenty of Python shops out there, and we don't hear horror stories of Python white space maintenance nightmares. Either the Python community is doing a good job of hiding these issues, or they really aren't issues in practice. Of the people I've talked to in-person about Python semantic white-space, the common threads are either: 1) It's different than what I'm used to. 2) It's cramping my style. My code is art, and restricting how I can structure my code is an affront to my very being.
    - jessaustin 13y ago
      I guess I'm in a third camp: 3) Python's semantic whitespace is so wonderful I'm baffled that most other programming languages don't have it. It's like they're coding with one eye shut: why not do this wonderful thing that makes everything easier?
      - pyre 13y ago
- simias 13y ago
  > Getting the indentation right should be the least of your worries if you have a good editor I never understood that. The whole problem for me is that the indentation being the only thing denoting blocks the editor can't know for sure how things should be indented, since it's not simply cosmetic. I haven't written a whole lot of Python but how do you even refactor python code? In C I can just copy paste a block of code from anywhere to anywhere (no matter the coding style in the source and destination file and the level of indentation) and then hit C-M-\ in emacs and have it reindent everything properly. In Python you have to make sure that everything is at the level of indentation it belongs to. If you refactor huge chunks of code it's easy to miss one fubar tab and have code subtly broken and introduce weird regressions. Also, regarding the OP and "focusing only on your code", I think we all feel that way about the language we're the most familiar with. For me that's C and I can't say I've had a "missing semicolon" compilation error in months of heavy use. Once you're used to the syntax it becomes automatic.
  - hharrison 13y ago
    Any good editor should be able to figure out the indents when pasting. I'm not an emacs user, but I'd be surprised if there wasn't a plugin with smart python pasting.
    - simias 13y ago
      My point is that it's not always possible for the editor to know what the indentation is supposed to be because it can't know what the code is supposed to do. Suppose you have code like this: [...] if a: b c [...] And then you paste some snippet you got from somewhere else between b and c: [...] if a: b pasted_snippet c [...] The editor cannot know how to indent that properly. It's not a problem in most other languages. Again, I'm not trying to say it's a deal breaker and Python is useless as a result, I just think it's a small mistake in the design of the language. It's like non-breaking switch/case in C, it doesn't make the language unusable but it is an annoyance.
      - pyre 13y ago
- mahyarm 13y ago
  The problem is larger multi-people projects. You need very strict editor/whitespace discipline, and you don't want to commit some sort of re-indent which touches every line of a file. That and the refactor issue is the main issue people have with the whitespace thing.
  - pyre 13y ago
    Which is why we have things like linters, pep8, and pre-commit hooks. :P
- ufmace 13y ago
  It's easy enough if you have only one editor on one computer that you use with only one language. If you mix and match a half-dozen editors on multiple computers running different OSes coding in different languages, then it gets messier. Especially when all of the editors have different ways to set preferences for whether to use spaces or tabs, how much space per tab/indent, and whether those preferences are for this session, this language, or permanent. What, am I the only one that does that?
  - pyre 13y ago
    One of my pet peeves with Emacs is the way that it indents things (at least by default), so you won't find me using it. :-P
drdeadringer 13y ago
"white space is semantic" Is this not true for webpages and journalism?
- frenchy 13y ago
  Semicolons are semantic in journalism too.
  - klibertp 13y ago
    As they are in Python: import os; import antigravity; # etc...
Ensorceled 13y ago
I used to think that way. But then I realized it forced all my co-workers to get their freakin' indenting correct.
Arnor 13y ago
Yeah, I hate when my language forces me to write pristine code...
manish_gill 13y ago
Eh, this argument is at least 10 years old now, isn't it? I don't even remember the last time I had a problem with whitespace in Python. Just use a decent editor (vim!) and you're golden. :)
collyw 13y ago
I disliked the whitespace thing at first, but after using it for a while I got used to it. Then when I had to go back to change some Perl code I realised the real beauty of it - you never get the problem of having unmatched braces when moving blocks of code around.
hnriot 13y ago
seriously? you should be properly indenting your code anyway, so it's not like python's making you do more than you should already.
Goladus 13y ago
It's ironic that you say that, given that if you don't get the whitespace correct, you'll have a syntax error. That's one of the big reason Python rubs me the wrong way: white space is semantic. Not to pile on but this is exactly backwards. The whitespace saves keystrokes and errors because it's giving a semantic meaning to something that programmers put in their code anyway. Now that I've actually written some code in ruby, I can't comprehend how rubyists aren't driven insane by the 'end' tokens. I'm sure this is a newbie mistake but on multiple occasions I've written something like this: def foo(x) if x > 5 puts x else puts 5 end foo(7) foo(3) Any experienced ruby programmers should see the error pretty quickly. But it LOOKS pretty good. Here is the error you get: test.rb:9: syntax error, unexpected $end, expecting kEND What's on line 9? That's just the end of the file. Nowhere near where the syntax error actually is. In this trivial example, tab-checking the indentation using my editor will reveal the error. But this is a trivial example. In more substantial code this technique is not nearly as effective. In erb templates its harder still. That never happened to me in python, even as a newbie. If I forget a colon I almost always know instantly because the editor will try to indent my code dramatically wrong. And if I inadvertently delete the colon at a later time without updating the indentation (this happens a lot) I get an instant syntax error that points me right at the line where the colon is missing. It's an error you can fix in your sleep. You don't forget end tokens because there are no end tokens to forget. The block ends when the indentation level decreases.

klrr 13y ago

So you are enabled to focus wholly since you are used to its syntax?

GlennS 13y ago
I really do think Python's convenience is more than just familiarity. I found it very quick to learn and easy to remember compared to other languages.

agumonkey 13y ago

Feels exactly the same about Lisp and other languages.

CmonDev 13y ago

Yeah, also who needs type checking when you can simply write dozens of unit tests!

qw 13y ago

I often forget ending for/while/if statements with a colon. http://markmail.org/message/ve7mwqxhci4pm6lw http://markmail.org/message/ve7mwqxhci4pm6lw In my opinion they should not be required because they cause more problems than they solve.

dkersten 13y ago

without ever worrying about if I misplaced a semi-colon or left out some weird punctuation I've seen enough code like [(foo[-1:self._bar:2]%(a,b),) for foo in quux] to not really believe that.

Goladus 13y ago
the parser is usually really good at spotting those errors and once they've been pointed out are trivial to correct.