| msg93205 - (view) |
Author: Rohde Fischer (rohdef) |
Date: 2009-09-28 12:26 |
| Although it's probably futile, I'll still give it a try. I can see in your tutorial that you desire 4 spaces over tabs. I have never seen a good argument for spaces (and I've seen a lot), so I'll try to convince that tabs is the way (god damn it we don't live in 1980 any more). From the tutorial: "Tabs introduce confusion, and are best left out." - only if you're switching in the middle of a document, tabs and spaces are equally confusing (I would say they're the opposite, but ok). There's no difference on that part. Then some of the arguments I've heard is that some editors shows tabs badly, although true, then most proper editors it's possible to adjust that to your personal preference, removing that possibility you are removing a nice (although not entirely needed) flexibility. In a program with 200 lines of code we have roughly 600 extra keystrokes with spaces, unless using a proper editor which shows tabs nicely. Tabs use less space, which is usable when uploading and downloading code a lot (which you do when using version control). Posting on forums is a problem with tabs. True, but then you can use proper utilities for that, and although I don't use forums for code issues I would seriously question the forum if a code-related forum didn't convert tabs, and even if it doesn't then I would still use a pastebin utility, since it offers all those nice features like syntax highlighting and auto conversion of tabs. 4 spaces is prettier than tabs converted to 8 spaces. True but yet again most editors can adjust that or actually use 4 spaces per default, but if I like 2 spaces I can't do that without introducing confusion, so spaces actually introduces more confusion than tabs. Good editors makes spaces transparent and behave like tabs, true but good editors also makes tabs look pretty. But editing manual spaces is hell compared to the ugliness of a bad editor, and I prefer usability over pretty. This don't look good with tabs string = "some multiline whatever string"+ " and continued" string = "some multiline whatever string"+ " and continued" True, but not unreadable, and if insisting on pretty you can switch to tabs for identation spaces for multiline prettyness. So until I see good arguments for spaces I would really like to see the standard switched to tabs, since I see no good reason for claiming spaces is better ... actually so see reason to claim otherwise. |
|
|
| msg93206 - (view) |
Author: R. David Murray (r.david.murray) *  |
Date: 2009-09-28 13:03 |
| Python started out using tabs, for some of the reasons you elaborate. Years of practical experience have shown that using tabs causes pain. Our recommendation is not going to change. |
|
|
| msg93230 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-09-28 20:01 |
| > Then some of the arguments I've heard is that some editors shows tabs > badly, although true, then most proper editors it's possible to adjust > that to your personal preference That is no option for Python. In Python, it is part of the LANGUAGE SYNTAX that a tab is 8 columns. Changing that may change the very meaning of a Python program (i.e. an editor configured to four column tabs may render a program to MEAN something different than when formatted to eight column tabs). So a tab is 8 columns, period. > In a program with 200 lines of code we have roughly 600 extra > keystrokes with spaces, unless using a proper editor which shows tabs > nicely. I think you should get a different editor then. I press tab in my editor and still get four spaces. > Tabs use less space, which is usable when uploading and downloading > code a lot (which you do when using version control). That's negligible, compared to the rest of the file. |
|
|
| msg93231 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2009-09-28 20:33 |
| Wow. You (rohdef) really do sound like you are a time capsule from the eighties. Tabs would save keystrokes and bandwidth, and are not confusing? The keystrokes argument is wrong for most editors; the bandwidth argument doesn't matter due to disk size, network speed, and compression; and the confusion is absolutely real. Pretty much every time I volunteer to help out a group of Python newbies there is at least one baffling problem due to tabs/spaces. There are hundreds of different text editors that people use on a regular basis to edit Python source code. They all display spaces the same way; not so for tabs. Most of them have configurable behavior for tabs, and most of the time the users are not aware of even the existence of those settings, let alone what setting is currently being used. |
|
|
| msg93257 - (view) |
Author: Rohde Fischer (rohdef) |
Date: 2009-09-29 07:31 |
| > Python started out using tabs, for some of the reasons you elaborate. > Years of practical experience have shown that using tabs causes pain. > Our recommendation is not going to change. I can't actually see why this should be the case, could you please enlighten me here? > > Then some of the arguments I've heard is that some editors shows > > tabs badly, although true, then most proper editors it's possible > > to adjust that to your personal preference > That is no option for Python. In Python, it is part of the LANGUAGE > SYNTAX that a tab is 8 columns. Changing that may change the very > meaning of a Python program (i.e. an editor configured to four column > tabs may render a program to MEAN something different than when > formatted to eight column tabs). I fail to see that this is possible, simply from the following reason (space after \t added for readability) if a<b: \t if b<c: \t\t # some code if that ends up as: if a<b: if b<c: # Some code or if a<b: if b<c: # Some code would be exactly the same (apart from how much space it takes). Unless the editor automatically wraps lines or some other - for programming - inappropriate things, then the code would be exactly the same as long as you use the same indentation all the way, no matter if it's interpreted as 2, 4, 8 or n spaces. As far as I can see no matter how complex the code is this wouldn't change, since 1st block = 1 tab | |
4 spaces, 2nd block = 2 tabs |
|
| msg93280 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2009-09-29 11:42 |
| I understand you're annoyed, but the bug tracker is not the place to rehash arguments that were settled a decade ago. If you need to pursue this, please take it to the newsgroup comp.lang.python. Before you do, you might want to scour the newsgroup's archives, as millions of words of debate on this topic have already taken place, mostly in the early to mid 90's. Nobody has anything new to say on this topic :-( Note that nobody objects if you want to use tabs, or even mix tabs and spaces, in your own code. The Python "spaces only" standard is for distributed code. Years of early experience taught us beyond doubt that tabs caused endless problems for /shared/ code, to the extent that the Python distribution contains utilities to detect when mixing tabs and spaces can cause semantic differences (tabnanny.py) and to reformat source files to replace all tabs with spaces (reindent.py). Indeed, if you want to contribute to the Python distribution and insist on using tabs, that's fine: simply run your code through reindent.py before submitting your patch. Otherwise, just like this feature request, your patch will be rejected ;-) |
|
|