[Piuparts-devel] Bug#698526: Sort known issues by reverse dependency count
Andreas Beckmann
anbe at debian.org
Thu Feb 21 10:02:53 UTC 2013
+ if self.inc_re.search( logbody, re.MULTILINE ):
+ for line in logbody.splitlines():
+ if self.inc_re.search( line ):
+ if self.exc_re == None \
+ or not self.exc_re.search(line):
+ return( True )
That looks inefficient. Why do we have to grep twice to identify
matching lines even if we have no exclusion pattern?
Is it for 'foo.*bar' matching on
'The food shop\n....\nSetting up libbar (08-15) ...'
? Hmm, no, DOTALL is off by default.
Anyway, once you have a match, it shouldn't be too difficult to find the
position and identify the matching line without needing to rematch on
each line individually.
Maybe even extend the pattern internally to
^.*($PATTERN)
to match at BeginOfLine, then add a search for '$' starting from the BoL
to find the corresponding EoL ... and apply the exclusion pattern on the
range found that way.
Disclaimer: I don't really have experience with python re
For combining patterns,
'(foo)|(bar)'
should return something in $1 or $2 depending on what matched (FSVO $1),
that should allow to identify the "pattern number", just ensure to
"escape" all inner parenthesis as (?:...)
Andreas
PS: for reviewing a series of patches I don't really care about the
author's development history but prefer "rebased, rewritten and
reordered history" to produce an easily readable patch series with small
and self contained patches. (Hint: please fold 'Template HTML format
fix' into the commit it fixes.) Of course rewriting is off limits once
something has been merged into mainline. But I see no gain in merging a
lot of "fixup" commits into mainline if the development branch could
have been rewritten before the merge.
Andreas
More information about the Piuparts-devel
mailing list