[MERGE] Patience diff

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
> 
>>> PEP8. Also, Bram seemed to like running self tests every time the module
>>> was imported. Which are what all these asserts are for.
>>> They should be fast, so I'm okay with keeping them, but I did add them
>>> to selftest, so it would be safe to get rid of them.
> 
> I think we should take them out, to be consistent with bzr style.  We're
> pretty clearly taking ownership of this code.
> 
>>> Did you re-run the tests with the new patience-test.py? I'm guessing it
>>> still worked, but just thought I would check.
> 
> Yes, I did.
>>> +        chk_blocks('abcdefghijklmnop'
>>> +                 , 'abcXghiYZQRSTUVWXYZijklmnop'
>>> +                 , [(0, 0, 3), (6, 4, 3), (9, 20, 7)])
>>> +
>>> +        chk_blocks('ABCd efghIjk  L'
>>> +                 , 'AxyzBCn mo pqrstuvwI1 2  L'
>>> +                 , [(0,0,1), (1, 4, 2), (4, 7, 1), (9, 19, 1), (12, 23,
>>> 3)])
>>> +
>>>
>>> Is this the best way to write it? Basically, I needed a multi-line code
>>> snippet, that I could do diff with, and make sure it gave a reasonable
>>> answer. (It also highlights the difference between difflib and
>>> patiencediff).
> 
> It looks okay, except that there shouldn't be leading commas; those
> should be on the previous line.

I guess it really wasn't clear. I was actually talking about the
chk_blocks('''\
big multiline text follows
''')

stuff.

I personally like the leading commas style. After I had seen it, I
realized that commas are logically attached more to the thing following
 than the thing proceeding. If you add something else, you put another
comma, python has a workaround where it will ignore a trailing comma, so
you can do lists like:
	[
	a,
	b,
	c,
	d,
	]

But this works in C:
	( a
	, b
	, c
	, d
	)

And means that if you add something it doesn't change the other lines.
(except for a, but that is less common).

Anyway, I try to avoid the style for bzr code, but this was written
before PEP8 was really firm, and it was originally just playing around code.

> 
>>> I suppose we could move the static text out of the function and into the
>>>  module scope, it may make it look a little cleaner. I don't really know
>>> what the 'best' thing here is.
> 
> I might do that for the bigger chunks.  Actually, I might rot13 the
> example taken from bzr source code, because it's hella confusing to see
> python function definitions as strings.

Yeah, especially without syntax highlighting, it is really hard to
figure out where things should be.
I have no problem using a different code snippet, just as long as it
demonstrates the behavior. (You need repeated lines, with a long trailer
of unmodified code)

> 
>>> Other than the few things, I think its just about ready to be merged. So
>>> +1 from me after they are handled.
> 
> Thanks.  Submitted.
> 
> Aaron
> 

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060523/770fa297/attachment.pgp