+ 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org