[MERGE] Patience diff
John A Meinel
john at arbash-meinel.com
Tue May 23 15:21:00 BST 2006
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,
>>> 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
> 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
big multiline text follows
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:
But this works in C:
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060523/770fa297/attachment.pgp
More information about the bazaar