Compare source code

Discussion in 'Python' started by jf, Oct 31, 2010.

  1. jf

    jf Guest

    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.
    jf, Oct 31, 2010
    #1
    1. Advertising

  2. > 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
    Martin v. Loewis, Oct 31, 2010
    #2
    1. Advertising

  3. jf

    jf Guest

    Le 31/10/2010 13:10, Martin v. Loewis a écrit :
    >> 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 ?

    >
    > 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
    jf, Oct 31, 2010
    #3
  4. > 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
    Martin v. Loewis, Oct 31, 2010
    #4
  5. In message <4ccd5ad9$0$19151$>, jf wrote:

    > I edit each file to remove tabs ...


    expand -i <oldfile >newfile

    > Do you know a tools to compare the initial file with the cleaned one to
    > know if the algorithms are the same ?


    diff -b oldfile newfile
    Lawrence D'Oliveiro, Oct 31, 2010
    #5
  6. jf

    Bob Martin Guest

    in 645437 20101031 230912 Lawrence D'Oliveiro <_zealand> wrote:
    >In message <4ccd5ad9$0$19151$>, jf wrote:
    >
    >> I edit each file to remove tabs ...

    >
    >expand -i <oldfile >newfile
    >
    >> Do you know a tools to compare the initial file with the cleaned one to
    >> know if the algorithms are the same ?

    >
    >diff -b oldfile newfile


    meld
    Bob Martin, Nov 1, 2010
    #6
  7. On Mon, 01 Nov 2010 12:09:12 +1300, Lawrence D'Oliveiro wrote:
    > In message <4ccd5ad9$0$19151$>, jf wrote:
    >
    >> I edit each file to remove tabs ...

    >
    > expand -i <oldfile >newfile
    >
    >> Do you know a tools to compare the initial file with the cleaned one to
    >> know if the algorithms are the same ?

    >
    > diff -b oldfile newfile


    Warning: "diff -b" won't detect changes in indentation. Changes in
    indentation can change a Python program.

    --
    To email me, substitute nowhere->spamcop, invalid->net.
    Peter Pearson, Nov 1, 2010
    #7
  8. In message <>, Peter Pearson wrote:

    > On Mon, 01 Nov 2010 12:09:12 +1300, Lawrence D'Oliveiro wrote:
    >
    >> In message <4ccd5ad9$0$19151$>, jf wrote:
    >>
    >>> I edit each file to remove tabs ...

    >>
    >> expand -i <oldfile >newfile
    >>
    >>> Do you know a tools to compare the initial file with the cleaned one to
    >>> know if the algorithms are the same ?

    >>
    >> 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...
    Lawrence D'Oliveiro, Nov 1, 2010
    #8
  9. On 2010-11-01, Lawrence D'Oliveiro <_zealand> wrote:
    > In message <>, 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.

    --
    Grant Edwards grant.b.edwards Yow! I'm continually AMAZED
    at at th'breathtaking effects
    gmail.com of WIND EROSION!!
    Grant Edwards, Nov 1, 2010
    #9
  10. On Mon, 1 Nov 2010 22:24:03 +0000 (UTC), Grant Edwards wrote:
    > On 2010-11-01, Lawrence D'Oliveiro <_zealand> wrote:
    >> In message <>, 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.
    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.

    --
    To email me, substitute nowhere->spamcop, invalid->net.
    Peter Pearson, Nov 1, 2010
    #10
  11. On 11/1/2010 3:18 PM Lawrence D'Oliveiro said...
    > In message<>, 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
    Emile van Sebille, Nov 1, 2010
    #11
  12. In message <>, 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?
    Lawrence D'Oliveiro, Nov 1, 2010
    #12
  13. jf

    Ian Guest

    On Nov 1, 4:48 pm, Peter Pearson <> 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
    Ian, Nov 1, 2010
    #13
  14. jf

    Seebs Guest

    On 2010-11-01, Grant Edwards <> wrote:
    > On 2010-11-01, Lawrence D'Oliveiro <_zealand> wrote:
    >> In message <>, 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.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.
    Seebs, Nov 2, 2010
    #14
  15. On 02 Nov 2010 04:16:28 GMT
    Seebs <> 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 <> | 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.
    D'Arcy J.M. Cain, Nov 2, 2010
    #15
  16. In message <>, 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.
    Lawrence D'Oliveiro, Nov 2, 2010
    #16
  17. On Mon, 01 Nov 2010 22:24:03 +0000, Grant Edwards wrote:

    > On 2010-11-01, Lawrence D'Oliveiro <_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
    Steven D'Aprano, Nov 2, 2010
    #17
  18. 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
    Steven D'Aprano, Nov 2, 2010
    #18
  19. 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
    Steven D'Aprano, Nov 2, 2010
    #19
  20. On 11/1/2010 4:22 PM Lawrence D'Oliveiro said...
    > In message<>, 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
    Emile van Sebille, Nov 2, 2010
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. alan jeeves
    Replies:
    10
    Views:
    6,248
    James D. Veale
    Mar 5, 2004
  2. Author Tarun Tyagi
    Replies:
    0
    Views:
    692
    Author Tarun Tyagi
    Dec 29, 2004
  3. alapick
    Replies:
    1
    Views:
    362
    Flash Gordon
    Sep 23, 2007
  4. Replies:
    3
    Views:
    590
  5. Rustom Mody

    Re: Compare source code

    Rustom Mody, Nov 5, 2010, in forum: Python
    Replies:
    7
    Views:
    195
    Seebs
    Nov 7, 2010
Loading...

Share This Page