On Sat, 06 Apr 2013 08:36:23 +0300, Timothy Madden wrote: > 8-character tab stops should be the default. Debating that is I believe > another topic, and compatibility with python2 should be enough to make > that debate unnecessary.
Compatibility with Python 2 is not a requirement. Python 3 exists to fix a bunch of design flaws and mistakes in Python 2. Among the changes: - print and exec are now functions, not statements - the dangerous input function is gone - raw_input is renamed input - the distinction between int and long is gone - the second-string "classic classes" are gone - strings are Unicode, not bytes - division is done correctly - the error-prone syntax of the "except" statement is fixed - inconsistently named modules are fixed - the plethora of similar dict methods is cleaned up - map, filter, zip operate lazily rather than eagerly and of course - mixed spaces and tabs for indentation is gone > You are right, to change the tab size means to change the meaning of the > code, and that would be wrong. Can't argue with that. I can argue with that. Changing tab size does *not* change the meaning of code, provided you *only* use tabs for indentation. Using only tabs for indentation is fine. Whether you set your editor to display tabs as 2 columns, 4 columns, 8 columns, or a thousand columns will make not a whit of difference to the meaning of the code or the number of indent levels. This is the Killer Feature of tabs, and it is the primary reason why tabs rule and spaces suck for indentation. (Alas, too many broken tools that can't handle tabs mean that the less- good standard won.) Using only spaces for indentation is also fine. Not as good as tabs, because if I use spaces, you're stuck reading my code in whatever poorly- thought out indent I might choose. I've seen developers use *one* space. But using only spaces does work. What does not work in general, is mixing the two. Don't mix them for indents, and you'll be fine. > What I want is an option to use the tabs as I have used them in the > past, with the default size. You can continue to use tabs, so long as you don't mix them with spaces. > Since "ambiguity" about the tab size > appears to be the cause for new python 3 rules, I though of an option > the make that size explicit. I still think users should somehow have a > way to use a tab stop of their choice, but how this could be achieved > properly is another problem. Unnecessary complexity to solve a non-problem. Just pick one, tabs or spaces, and consistently use it in any one block of code. You don't even have to be consistent over an entire file. > I guess a discussion like this thread is the price to be paid for > relying solely on white space to delimit code blocks, like the python > syntax does. Mixing spaces and tabs for indentation is bad in brace languages too. http://mailman.linuxchix.org/pipermail/programming/2004-August/001433.html Maybe if we had smarter editors and smarter diffs and smarter tools in general, it wouldn't be a problem. But we don't, so it is. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
