5 ms·

Presumably if its a problem, the accidental change in indentation changed the code to a wrong form, rather than a form that can't be parsed (i.e. unindenting in

Presumably if its a problem, the accidental change in indentation changed the code to a wrong form, rather than a form that can't be parsed (i.e. unindenting in the middle of a block, which will just cause easy-to-identify indentation errors). Think about the same situation in, say, C. Now, your program still compiles correctly - but people read it as doing something differently. I'd argue that its worse to accidentally disconnect a reader's interpretation from a compiler's than to change both of them to something that's logically incorrect.

lisper 15y ago
I agree. But those are not our only choices. The ironic thing about Python is that it actually does have an open-brace. It's the colon. The compiler can tell that this: def foo(): baz() is syntactically incorrect. And if you tab the second line, auto-indent can do the Right Thing. The screw case is this: def foo(): if baz: bar() bing() boff() If you auto-indent the last line, it will quietly change the semantics of your program. That's bad. I always end my blocks with a PASS statement (or a return), i.e.: def foo(): if baz: bar() bing() pass boff() return If you do this, then auto-indent will always do the Right Thing. This is particularly beneficial if you want to take a big block of code and wrap in an an outer block. I can add two lines to the above code: def foo(): while snoz: <-- if baz: bar() bing() pass boff() pass <-- return Then I can just auto-indent the whole thing and be confident that the result will be correct. Contrast this with the traditional method where you have to manually re-indent your code. If you accidentally select the wrong region to re-indent you can change the semantics of the code in a way that loses the information about what the semantics should have been. The only way to recover from this is to manually reconstruct the correct semantics. It may not happen very often, but when it does it's a colossal PITA. (Entering those examples was a colossal PITA too.)
- thedufer 15y ago
  Wait, so you reconstruct the end delimiter using pass? That's one of the least-pythonic things I've ever seen. I really don't see how this could end up being a problem - doing a block indent shouldn't be this difficult.
  - lisper 15y ago
    > Wait, so you reconstruct the end delimiter using pass? Yes. > That's one of the least-pythonic things I've ever seen. What can I say? It works. > I really don't see how this could end up being a problem Do you use emacs? Open up two windows, each with an emacs editing some python code in python mode. Cut and paste some code from one window into the other.
    - thedufer 15y ago
      I don't use emacs, but I use vim, and I suspect I've seen the problem you're talking about. Its the one where auto-indent puts extra indentation in pasted code? This is a problem of not knowing how to use your editor. For example, in vim I either open files in tabs (and use the vim yank buffer/clipboard) in the same editor, or go into `paste` mode to paste from the OS clipboard. I'm not sure what the solution is in emacs, but I guarantee there is one.
      - snoble 15y ago
        Ah ha! you guys weren't arguing about whitespace in code at all. This thread is just a proxy war for the vim/emacs holy war. I should have guessed.
        itmag 15y ago
        "Proxy war", lol :p Does that mean that nano and notepad will be recruited to do the actual fighting in the jungles of Vi-ed-nam?
    - deleted 15y ago
      [deleted]

lisper 15y ago

I agree. But those are not our only choices. The ironic thing about Python is that it actually does have an open-brace. It's the colon. The compiler can tell that this: def foo(): baz() is syntactically incorrect. And if you tab the second line, auto-indent can do the Right Thing. The screw case is this: def foo(): if baz: bar() bing() boff() If you auto-indent the last line, it will quietly change the semantics of your program. That's bad. I always end my blocks with a PASS statement (or a return), i.e.: def foo(): if baz: bar() bing() pass boff() return If you do this, then auto-indent will always do the Right Thing. This is particularly beneficial if you want to take a big block of code and wrap in an an outer block. I can add two lines to the above code: def foo(): while snoz: <-- if baz: bar() bing() pass boff() pass <-- return Then I can just auto-indent the whole thing and be confident that the result will be correct. Contrast this with the traditional method where you have to manually re-indent your code. If you accidentally select the wrong region to re-indent you can change the semantics of the code in a way that loses the information about what the semantics should have been. The only way to recover from this is to manually reconstruct the correct semantics. It may not happen very often, but when it does it's a colossal PITA. (Entering those examples was a colossal PITA too.)

thedufer 15y ago
Wait, so you reconstruct the end delimiter using pass? That's one of the least-pythonic things I've ever seen. I really don't see how this could end up being a problem - doing a block indent shouldn't be this difficult.
- lisper 15y ago
  > Wait, so you reconstruct the end delimiter using pass? Yes. > That's one of the least-pythonic things I've ever seen. What can I say? It works. > I really don't see how this could end up being a problem Do you use emacs? Open up two windows, each with an emacs editing some python code in python mode. Cut and paste some code from one window into the other.
  - thedufer 15y ago
    I don't use emacs, but I use vim, and I suspect I've seen the problem you're talking about. Its the one where auto-indent puts extra indentation in pasted code? This is a problem of not knowing how to use your editor. For example, in vim I either open files in tabs (and use the vim yank buffer/clipboard) in the same editor, or go into `paste` mode to paste from the OS clipboard. I'm not sure what the solution is in emacs, but I guarantee there is one.
    - snoble 15y ago
      Ah ha! you guys weren't arguing about whitespace in code at all. This thread is just a proxy war for the vim/emacs holy war. I should have guessed.
      - itmag 15y ago
        "Proxy war", lol :p Does that mean that nano and notepad will be recruited to do the actual fighting in the jungles of Vi-ed-nam?
  - deleted 15y ago
    [deleted]