On 2010-11-03, Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > On Tue, 02 Nov 2010 19:26:56 +0000, Tim Harig wrote: >> I agree with Seebs, Python is the only language I know that promotes the >> use of spaces over tabs;
> Really? Yes. > I'm not aware of *any* language that promotes tabs over spaces. Makefiles. > I > thought the tabs vs spaces war was mostly won by spaces over a decade ago > (apart from a few plucky freedom fighters who will never surrender). No. However, you've got a fallacy of the excluded middle here -- you're ignoring the very large set of "doesn't care either way", and looking only at things that prefer one or the other. > So, I bite my lip, stop using broken tools that make dealing with space- > indents painful, and just deal with it. And you know what? It's not so > bad after all. I don't consider it broken for a tool to favor a more logical style which is *actually* required by at least one format, and not a problem for anything I've ever used except (sort of) Python. In fact, Python works perfectly with tabs; it's just other Python programmers who get fussy. :) > Their loss. I don't miss the flame wars over the One True Brace Style. > There are enough disagreements over coding conventions without adding to > them. I don't miss them, or care about them; after all, I can just run indent/cb to format something however I like, and run it again to match any given coding style standard. Problem solved. > * it's not an issue for thousands of other users; This is a non-argument. That something isn't a problem for other people makes no difference to the people for whom it's a problem. > * even if it were an issue, if you use the right tool for the job, the > issue disappears; I have never found any other editor that I like as much as the one I use now. > * and even if there is no right tool for the job, the feature isn't going > to change; I think you miss the point of the observation. I'm not expecting it to change; I'm pointing out that insisting that it's not a problem is *insulting* to the people for whom it is a problem. > * and even if it would change, the people doing the whinging aren't going > to volunteer to make the change. Oh, I'd happily contribute code if it'd matter. But it wouldn't. >> It would be much better if the community would simply acknowledge that >> this is a tradeoff the the language has made and one which is often >> misunderstood by many first time Python programmers. > Been there, done that. This is *old news*. I haven't seen it done yet. I've seen a whole lot of people tell me that an editor I've been using for twenty years is "broken" because I found a program that is brittle with regards to its inputs that is prone to being triggered by a behavior which has been free of problems (and indeed in some cases *mandatory*) for everything else. I've seen people smugly tell me that I'd love this if I just tried it. That didn't work for pickles, it didn't work for Player-vs-Player fighting in video games, and it's not gonna work for the lack of end markers. Explicit is better than implicit. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list