[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