Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Compare source code

 
 
Grant Edwards
Guest
Posts: n/a
 
      11-02-2010
On 2010-11-01, Peter Pearson <(E-Mail Removed)> wrote:
> On Mon, 1 Nov 2010 22:24:03 +0000 (UTC), Grant Edwards wrote:
>> On 2010-11-01, Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote:
>>> In message <(E-Mail Removed)>, Peter Pearson wrote:
>>>>
>>>>> diff -b oldfile newfile
>>>>
>>>> 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.

>
> True, but diff doesn't come with an "ignore curly braces" option.


True, but the fact that diff has an option that for Python sources
will produces useless results doesn't seem like a valid indictment of
Python's syntax and semantics.

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


However, the human brain does treat whitespace as significant.

--
Grant Edwards grant.b.edwards Yow! I joined scientology
at at a garage sale!!
gmail.com
 
Reply With Quote
 
 
 
 
Grant Edwards
Guest
Posts: n/a
 
      11-02-2010
On 2010-11-02, Seebs <(E-Mail Removed)> wrote:
> On 2010-11-01, Grant Edwards <(E-Mail Removed)> 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.

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


And you think compatibility with your broken e-mail server is a good
reason to change the syntax of a programming language?

> Many editors helpfully convert spaces to tabs by default some or all
> of the time. And so on.


Such editors are broken.

> The more I use it, the more I think it was an interesting experiment
> which has worked out about as well as scanf.


I think it's brilliant (indentation that actually means something, not
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.


They're only possible if you put redundant block markers in the
source.

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


Then you're doing something terribly wrong. I find indentation-based
structure to be completely effortless. Are you using an editor that
doesn't have a Python mode?

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


I suppose you can add comments to Python if you some syntactically
null "redudundacy" to indicate the intended structure. Personally,

--
Grant Edwards grant.b.edwards Yow! I'm having a
at quadrophonic sensation
gmail.com of two winos alone in a
steel mill!
 
Reply With Quote
 
 
 
 
Grant Edwards
Guest
Posts: n/a
 
      11-02-2010
On 2010-11-02, Steven D'Aprano <(E-Mail Removed)> wrote:

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


I've tripped over that as well. Not very often, but it's a bigger
problem than significant whitespace. I must admit that the first few
minutes I worked with Python having significant whitespace seemed
awkward -- probably because it invoked unpleasant memories of Fortran
IV on punch-cards.

After a short time, I suddenly realized that Python got it right: the
compiler and my brain are using the _same_thing_ to denote program
structure. All those years of my brain using one thing and the
compiler using a different thing were (and are) obviously the wrong
way to do it.

--
Grant Edwards grant.b.edwards Yow! My BIOLOGICAL ALARM
at CLOCK just went off ... It
gmail.com has noiseless DOZE FUNCTION
and full kitchen!!
 
Reply With Quote
 
Seebs
Guest
Posts: n/a
 
      11-02-2010
On 2010-11-02, D'Arcy J.M. Cain <(E-Mail Removed)> wrote:
> You have problems. Indentation as syntax isn't one of them.


In the absence of indentation as syntax, they haven't bugged me.

> "No one
> knows why" email is being "magically" transformed?


Yay for a large company IT department with both MS and Blackberry
stuff involved.

> Your editor has a
> mind of its own? Yikes!


It is extremely useful to me to have spaces converted to tabs
for every other file I edit.

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


Could be. But really, I've simply never seen a real problem with
flow/indentation mismatches in C.

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


No, they aren't. See... That would work *if I knew for sure what the intent
was*.

if foo:
bar
else:
baz
quux

Does it look right? We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.

So the only way I can figure that out is by fully figuring out the function
of all the code bits -- meaning I have to fully understand the code, same
as I would to debug the C. The fact that indentation is flow control
just means I have only one set of cues, so I can't watch for mismatches.

-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
 
Seebs
Guest
Posts: n/a
 
      11-02-2010
On 2010-11-02, Steven D'Aprano <(E-Mail Removed)> wrote:
> I've lost more time to reading people's bitching about indentation than I
> have dealing with indentation problems.


Doesn't totally surprise me.

> But then, I don't insist on using tools which are broken by design.


Neither do I.

> If your email server converts plain text to HTML, it is broken.


Yup. I have an open ticket with the IT department.

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


Yes. But that's the thing -- I *want* that behavior for every other tool,
file format, or other thing I work with.

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


I have made no such insistance. I have not said Python should change. I
have not said other people should want what I want. I'm not the one telling
other people that editors they've used happily for twenty years without
any problems are clearly wrong.

I have merely observed that Python is, in this respect, gratuitously
brittle. It doesn't observe the robustness principle; it is
conservative in what it accepts, and in particular, is vulnerable to a
category of problem which is fairly common, well-known, and likely to
remain common for the next few decades.

There are reasons for it to be this way, and I don't object to the
existence of people who prefer that side of the tradeoff. I do dislike
it when people smugly tell me off for having different preferences.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (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
 
Grant Edwards
Guest
Posts: n/a
 
      11-02-2010
On 2010-11-02, Seebs <(E-Mail Removed)> wrote:
> On 2010-11-02, D'Arcy J.M. Cain <(E-Mail Removed)> wrote:
>> You have problems. Indentation as syntax isn't one of them.

>
> In the absence of indentation as syntax, they haven't bugged me.
>
>> "No one
>> knows why" email is being "magically" transformed?

>
> Yay for a large company IT department with both MS and Blackberry
> stuff involved.
>
>> Your editor has a
>> mind of its own? Yikes!

>
> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.
>
>>> 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.

>
> Could be. But really, I've simply never seen a real problem with
> flow/indentation mismatches in C.
>
>>> 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.

>
> No, they aren't. See... That would work *if I knew for sure what the intent
> was*.
>
> if foo:
> bar
> else:
> baz
> quux
>
> Does it look right? We have *no idea*, because we don't actually know
> whether quux was *intended* to be in the else branch or whether that's a typo.
>
> So the only way I can figure that out is by fully figuring out the function
> of all the code bits -- meaning I have to fully understand the code, same
> as I would to debug the C. The fact that indentation is flow control
> just means I have only one set of cues, so I can't watch for mismatches.


You can add redundant, semantically empty structure info to Python
programs just as easily as you can to C programs:

if foo:
bar
else:
baz
quux
#endif


--
Grant Edwards grant.b.edwards Yow! With YOU, I can be
at MYSELF ... We don't NEED
gmail.com Dan Rather ...
 
Reply With Quote
 
Emile van Sebille
Guest
Posts: n/a
 
      11-02-2010
On 11/2/2010 10:58 AM Seebs said...
> No, they aren't. See... That would work *if I knew for sure what the intent
> was*.
>
> if foo:
> bar
> else:
> baz
> quux
>
> Does it look right? We have *no idea*, because we don't actually know
> whether quux was *intended* to be in the else branch or whether that's a typo.


What is right is that there's no question that quux is subsequent to baz
in all cases barring exceptions (and assuming no tabs intermixed)

The apparent structure in python _is_ the structure, whereas otherwise
you've got to count your ;'s and {}'s etc to determine and verify the
structure matches the apparent structure provided by the programmer.

Whether that's what the specs called for or not is always a source for bugs.

Emile




 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      11-02-2010
On 2010-11-02, Emile van Sebille <(E-Mail Removed)> wrote:
> On 11/2/2010 10:58 AM Seebs said...
>> No, they aren't. See... That would work *if I knew for sure what the intent
>> was*.
>>
>> if foo:
>> bar
>> else:
>> baz
>> quux
>>
>> Does it look right? We have *no idea*, because we don't actually know
>> whether quux was *intended* to be in the else branch or whether that's a typo.

>
> What is right is that there's no question that quux is subsequent to baz
> in all cases barring exceptions (and assuming no tabs intermixed)
>
> The apparent structure in python _is_ the structure, whereas otherwise
> you've got to count your ;'s and {}'s etc to determine and verify the
> structure matches the apparent structure provided by the programmer.
>
> Whether that's what the specs called for or not is always a source
> for bugs.


Yup. I've never found that the ability to write incorrect code that
_appears_ correct to be a good thing. Nor do I find the ability to
write correct code that appears to be incorrect to be valuable.

In Python, if the structure looks right, then structure _is_ right.

--
Grant Edwards grant.b.edwards Yow! Now we can become
at alcoholics!
gmail.com
 
Reply With Quote
 
D'Arcy J.M. Cain
Guest
Posts: n/a
 
      11-02-2010
On 02 Nov 2010 17:58:06 GMT
Seebs <(E-Mail Removed)> wrote:
> On 2010-11-02, D'Arcy J.M. Cain <(E-Mail Removed)> wrote:
> > "No one
> > knows why" email is being "magically" transformed?

>
> Yay for a large company IT department with both MS and Blackberry
> stuff involved.


"Large" is no excuse for incompetency.

> > Your editor has a
> > mind of its own? Yikes!

>
> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.


So configure it to recognize Python files and act accordingly.

> No, they aren't. See... That would work *if I knew for sure what the intent
> was*.
>
> if foo:
> bar
> else:
> baz
> quux
>
> Does it look right? We have *no idea*, because we don't actually know
> whether quux was *intended* to be in the else branch or whether that's a typo.


And C has the same problem.

if (foo)
bar;
else
baz;

quux;

Is quux meant to be part of the else clause? The writer's indentation
suggests "yes" but the code says "no".

> So the only way I can figure that out is by fully figuring out the function


Same is true for the C code. In both cases you can tell what the code
will do (modulo weird macros in the C code) but the intention is
impossible to determine without mind reading abilities in both cases.
We do know that the Python code *appears* to be doing exactly what the
author intended and the C code *appears* to not be.

In either case, <syntax checker> != <debugger>.

--
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
 
D'Arcy J.M. Cain
Guest
Posts: n/a
 
      11-02-2010
On Tue, 2 Nov 2010 18:15:03 +0000 (UTC)
Grant Edwards <(E-Mail Removed)> wrote:
> You can add redundant, semantically empty structure info to Python
> programs just as easily as you can to C programs:
>
> if foo:
> bar
> else:
> baz
> quux
> #endif


"Redundant" is right. However, there is a use for such comments:

if foo:
bar
else:
baz
if snafu:
cookie
#endif snafu
quux
#endif foo

Useful in more complicated code, of course.

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