A simply newbie question about ndiff

[Neville Franks]

"Tim Peters" <tim.one at comcast.net> wrote in message
news:mailman.1019493956.28198.python-list at python.org...
> [Neville Franks]

> snip...

> > I only discovered your ndiff over the weekend, which is a little
> > surprising as I've also been working on Diff's for quite a few
> > years now as part of my programmer's editor, ED for Windows.
>
> Cool.  ndiff will do a fine job for you, but if you're slinging giant
files
> you'll need to compromise.
>
>..
> Now SequenceMatcher uses a much cleverer implementation than that
> brute-force triply-nested loop (which, as written, has worst-case cubic
> time), but it can still take substantial time, and 70K lines is
ridiculously
> out of the range of sizes ndiff was intended to handle.  70K is in the
range
> of a very long novel; the ndiff algorithm was first used to create
> human-readable patches for source code files, and later for plain-ASCII
> design documents.  Those typically take a few seconds.


Well believe it or not but there are quite a few people using ED that have
source files in excess of 70K. Not something I would advocate but ...

On a more serious note I do have folks who compare large'ish data (ascii
text) files. These are typically dumps of some sort. Apart from being large
they can also get less than optimal results as they can have large numbers
of repeated lines which throws my diff out.

I've organized a copy of ED for you to play with and would be interested to
hear what you think of it's Diff capabilities. ED doesn't have Python
support just yet, but it is planned. It does support some 34+ languages
though. A Free Trial is available at www.getsoft.com for anyone else who may
be interested.

--
Neville Franks, Author of ED for Windows - http://www.getsoft.com