Compare source code

Seebs usenet-nospam at
Tue Nov 2 05:16:28 CET 2010

On 2010-11-01, Grant Edwards <invalid at invalid.invalid> wrote:
> On 2010-11-01, Lawrence D'Oliveiro <ldo at geek-central.gen.new_zealand> wrote:
>> In message <8j8am4Fk2jU1 at>, Peter Pearson wrote:
>>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>>> indentation can change a Python program.

>> I'm getting less and less keen on that particular feature of Python...

> Why?

> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.


> For exmaple, if you remove all of the curly-braces from two C source
> files before comparing them, you don't get useful results.


But there's no *reason* to do that, while there are many common daily
events which result in whitespace changes.  e.g., any email sent
to my work account is being magically transformed into HTML (no one
knows why) on the server, so I can't get correct indentation except
in attachments.  Many editors helpfully convert spaces to tabs
by default some or all of the time.  And so on.

The more I use it, the more I think it was an interesting experiment
which has worked out about as well as scanf.  The "problem" it fixes
is something that's hardly ever been a problem for me in C or
related languages -- and which could be completely eliminated by
automated indenters, which were actually conceptually possible.

I've lost more time to indentation issues in Python in a month than
I've lost to mismatches between indentation and flow in C in twenty
years.  In theory, it sounds like it would help to eliminate the
ambiguity.  In practice, eliminating the question of whether code
was intended to follow explicit flow rather than indentation just
means that when there's a mistake you don't even get a warning that
someone was confused.

At least in C, if I see:
	if (foo)

I *know* that something is wrong.

Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam at <-- lawsuits, religion, and funny pictures <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

More information about the Python-list mailing list