Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Compare source code

Reply
Thread Tools

Compare source code

 
 
Emile van Sebille
Guest
Posts: n/a
 
      11-01-2010
On 11/1/2010 3:18 PM Lawrence D'Oliveiro said...
> In message<(E-Mail Removed)>, Peter Pearson wrote:

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


That feature being indentation based structure? At least you can look
at python code and _know_ that spurious placement of required line noise
don't have the ability to impact what the code does.

Emile

 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-01-2010
In message <(E-Mail Removed)>, Emile van
Sebille wrote:

> At least you can look at python code and _know_ that spurious placement of
> required line noise don't have the ability to impact what the code does.


But it does. What is spurious whitespace if not noise, after all?
 
Reply With Quote
 
 
 
 
Ian
Guest
Posts: n/a
 
      11-01-2010
On Nov 1, 4:48*pm, Peter Pearson <(E-Mail Removed)> wrote:
> True, but diff doesn't come with an "ignore curly braces" option.
> I'm not personally repelled by Python's use of significant indentation,
> but I must concede that some awkwardness results from assigning
> significance to something (whitespace) that many tools are inclined
> to treat as insignificant.


Beyond Compare at least is smart enough to know that leading
whitespace is significant in .py files, using the default
configuration.

Cheers,
Ian
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      11-02-2010
On 2010-11-01, Grant Edwards <(E-Mail Removed)> wrote:
> On 2010-11-01, Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote:
>> In message <(E-Mail Removed)>, 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.


Sure.

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


Right.

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)
a;
else
b;
c;

I *know* that something is wrong.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / http://www.velocityreviews.com/forums/(E-Mail Removed)
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.
 
Reply With Quote
 
D'Arcy J.M. Cain
Guest
Posts: n/a
 
      11-02-2010
On 02 Nov 2010 04:16:28 GMT
Seebs <(E-Mail Removed)> wrote:
> 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.


You have problems. Indentation as syntax isn't one of them. "No one
knows why" email is being "magically" transformed? Your editor has a
mind of its own? Yikes!

> 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


Your experience is 180 from mine.

> 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)
> a;
> else
> b;
> c;
>
> I *know* that something is wrong.


Does it look right? With Python looking right and being right are the
same thing. Once I realized that indentation should only be done using
spaces in Python I never had a problem. I certainly had problems with
C when the code looked right. Sometimes you can't even see the problem
because it's hidden in a badly defined macro.

--
D'Arcy J.M. Cain <(E-Mail Removed)> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-02-2010
In message <(E-Mail Removed)>, Seebs wrote:

> At least in C, if I see:
> if (foo)
> a;
> else
> b;
> c;
>
> I *know* that something is wrong.


This is why, when I started learning Python, I soon developed the habit of
inserting explicit “#end” markers. To Pythonize your example my way, it
would have come out as

if foo :
a
else :
b
#end if
c

which should also give a hint that something might be wrong.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-02-2010
On Mon, 01 Nov 2010 22:24:03 +0000, Grant Edwards wrote:

> On 2010-11-01, Lawrence D'Oliveiro <(E-Mail Removed)_zealand>
> wrote:

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


Ah, but other languages don't make the guarantee that you can add or
remove random whitespace in arbitrary places and still have code that
works correctly!

Of course, neither does Python, but there's a certain type of personality
that is never happy unless they are bitching and moaning, and if they
can't find something more substantial to bitch and moan about, they'll
bitch and moan about the fact that they can't make random changes to
syntactically significant tokens in their source code without things
breaking. Boo hoo, cry me a river.

Personally, I'm more disturbed by the default prompt in the interactive
interpreter. >>> clashes with the symbol used for quoting text in email
and news. That causes me far more distress than indentation.


Doing a bit of my own bitching and moaning'ly y'rs,


--
Steven
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-02-2010
On Mon, 01 Nov 2010 22:48:16 +0000, Peter Pearson wrote:

> I must concede that some awkwardness results from assigning significance
> to something (whitespace) that many tools are inclined to treat as
> insignificant.


Then the tools are broken.

Or perhaps I should say:

Th enth etool sarebroke n.


--
Steven
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-02-2010
On Tue, 02 Nov 2010 04:16:28 +0000, Seebs wrote:

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


I suppose then you're going to insist that Python should stop using > and
< for comparison operators, because your mail server converts them to
&gt; and &lt; escapes?


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


I've lost more time to reading people's bitching about indentation than I
have dealing with indentation problems.

But then, I don't insist on using tools which are broken by design. If
your email server converts plain text to HTML, it is broken. If your
editor changes spaces to tabs, or visa versa, without being told to do so
(either by an explicit command or an obvious setting), then your editor
is broken.

If you are stuck with broken mail servers and broken editors and broken
tools because of political reasons, then you have my sympathy. But stop
insisting that everybody has to carry the overhead of your work-arounds
for your broken tools.



--
Steven
 
Reply With Quote
 
Emile van Sebille
Guest
Posts: n/a
 
      11-02-2010
On 11/1/2010 4:22 PM Lawrence D'Oliveiro said...
> In message<(E-Mail Removed)>, Emile van
> Sebille wrote:
>
>> At least you can look at python code and _know_ that spurious placement of
>> required line noise don't have the ability to impact what the code does.

>
> But it does. What is spurious whitespace if not noise, after all?


But it does so by intent. Other languages lend only an appearance of
structure through the indentation style of the writer. It's as good as
outdated comments.

Emile

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Compare source code Rustom Mody Python 7 11-07-2010 04:28 AM
Hot to compare source code with different multiling formatting? bad.skipper@gmail.com C Programming 3 02-04-2009 10:33 PM
Open source project on C++ to compare XML as ExamXML. alapick C Programming 1 09-23-2007 09:23 PM
Data Recovery SOURCE CODE ( SOURCE CODES of Professional Data Recovery Software ) Author Tarun Tyagi Cisco 0 12-29-2004 05:03 PM
need a tool to compare java source files alan jeeves Java 10 03-05-2004 02:22 AM



Advertisments