Compare source code

J

jf

Hi,

I've a project with tabs and spaces mixed (yes I know it's bad).

I edit each file to remove tabs, but it's so easy to make a mistake.
Do you know a tools to compare the initial file with the cleaned one to
know if the algorithms are the same ?
By comparing pyc files for example.

Thanks.
 
M

Martin v. Loewis

I've a project with tabs and spaces mixed (yes I know it's bad).
I edit each file to remove tabs, but it's so easy to make a mistake.
Do you know a tools to compare the initial file with the cleaned one to
know if the algorithms are the same ?
By comparing pyc files for example.

Tools/scripts/reindent.py of the standard Python distribution normalizes
white space in source code. It is used to maintain normalized
indentation in the Python library itself, but you can certainly use it
also for your own files :)

Regards,
Martin
 
J

jf

Le 31/10/2010 13:10, Martin v. Loewis a écrit :
Tools/scripts/reindent.py of the standard Python distribution normalizes
white space in source code.

So great, you save my time !
Should I be worry about this comment in reindent.py "So long as the
input files get a clean bill of health from tabnanny.py, reindent should
do a good job." ?

Thanks
 
M

Martin v. Loewis

Should I be worry about this comment in reindent.py "So long as the
input files get a clean bill of health from tabnanny.py, reindent should
do a good job." ?

I don't think so: IIUC, this is about comments that are not reasonably
aligned with preceding or following code lines, most likely, you don't
have such comments in your files.

Regards,
Martin
 
L

Lawrence D'Oliveiro

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

Grant Edwards

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

Peter Pearson

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

Emile van Sebille

On 11/1/2010 3:18 PM Lawrence D'Oliveiro said...
In message<[email protected]>, Peter Pearson wrote:

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
 
L

Lawrence D'Oliveiro

Emile van said:
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?
 
I

Ian

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
 
S

Seebs

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
 
D

D'Arcy J.M. Cain

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

Lawrence D'Oliveiro

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

Steven D'Aprano

On 2010-11-01, Lawrence D'Oliveiro <[email protected]_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,
 
S

Steven D'Aprano

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

Steven D'Aprano

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

Emile van Sebille

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?[/QUOTE]

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top