Compare source code

[Tim Harig]

On 2010-11-03, Steven D'Aprano <steve at 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? I'm not aware of *any* language that promotes tabs over spaces. 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).

Python is the only language that I know that *needs* to specify tabs versus
spaces since it is the only language I know of which uses whitespace
formating as part of its syntax and structure.  Mixed usage may be annoying
in other languages; but, it breaks Python.

Otherwise, it is my experience that the preference for tabs versus spaces
depends on the users chosen platform.  *nix users prefer tabs while Windows
users prefer spaces.

>> and there are equally picky syntaxs (ie,
>> Makefiles) that mandate the use of tabs.  I personally prefer tabs as it
>> lets *me* decide how far the apparent indentations are in the code. You
>> may like four spaces; but, I agree with Linus Torvalds that eight spaces
>> is much clearer.  The beautiful thing about tabs is that we can both set
>> our tab stops to match our own viewing preferences.
>
> Actually I agree with you about tabs. I think tabs are far more logical 
> and sensible. But I'm stuck with broken tools that don't deal with tabs, 

Where you not the one a few posts back telling Seebs that he needed to
change his broken tools?

> and with PEP 8 that mandates the use of spaces, and popular opinion that 
> says make is crazy for using tabs.

Stupid rules are meant to be broken.

> 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.

If I am using somebody elses project, then I will post my output using
their code conventions.  I have smart conversion scripts that convert
between different indent formats.  I edit in the format that I prefer and,
in my projects, the indentation in the SCM is in my preferred format.

>> This is Python's most noticable blemish outside of the community.
>> Everybody knows that Python is the language that forces you to use a
>> particular style of formatting; and, that is a turn-off for many people.
>
> 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.

This choice has obviously not been effective in stopping flame wars.  I can
cite multiple threads where it has caused them.

>> It is a big mistake that whenever the issue arises, the community
>> effectively attacks anybody who might have disagreements with the
>> tradeoffs made for the Python language.  This tends to set people on the
>> defensive and gives them a bad taste about the language as a whole.
>
> That's very insightful. Why don't you apply some of that insight to the 
> other side? It is *incredibly* annoying to see the same old people making 
> the same old snide remarks about the same old issues over and over again, 
> particularly when:

A large part of the reason that the issue keeps coming up is that the
community never really deals with it when it does.  I have enough customer
support experience to know that a client is never really satisfied until
you acknowledge their problem.  Until the problem is acknowledged, the
client will have put up psychological communcation block that prevents
them from hearing any workarounds that you might have.

The community never acknowledges the problem.  It simply sweeps the
problem under the rug telling the people raising these issues that they
don't know what they are talking about; strengthening the psychological
block and further impeding the communication.  The people with these
problems therefore never feel that they have been heard, become unwilling
to listen to the solutions,  and will thus keep bringing the problem
back up.

> * it's not an issue for thousands of other users;

You are now hearing the testimony of those who have had problems.  I also
know that it is human nature for advocates to simply overlook the problems
when they arise.  That doesn't mean that the problem is there.

I have used Python for over a decade in spite of its problems because I
believe that the benefits outway the detriments.  I am however objective
enough to be congnizant of the problems; and, I am fully aware of there
effects on new members of the community.

When prospective Python programmers approach me with these problems I:

	1. Acknowledge that the problem exits.

	2. Explain the trade-offs that have lead to the problem.
	
	3. Suggest ways to work around the problem.
	
	4. Point out why I believe the benefits of using Python outway its
		idiosyncrasies.

I don't just tell them that there is no problem or that the problems they
may be experiencing are their fault because they choose to do something
differently then I might.

> * even if it were an issue, if you use the right tool for the job, the 
> issue disappears;

That a tools is needed is in itself an indication that the problem exists.
That isn't to say that good tools don't have their place or that they
cannot contribute to the solution.

> * and even if it would change, the people doing the whinging aren't going 
> to volunteer to make the change.

Funny that.  I *do* have a history of submitting patches to open source
projects.

>> 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*.

Except that you are not.  Your general attitude is that since you don't
experience problems nobody else must either.