Why re.match()?
John Machin
sjmachin at lexicon.net
Wed Jul 1 21:20:29 EDT 2009
On Jul 2, 9:50 am, MRAB <pyt... at mrabarnett.plus.com> wrote:
> Carl Banks wrote:
> > On Jul 1, 10:56 am, kj <no.em... at please.post> wrote:
> >> For a recovering Perl-head like me it is difficult to understand
> >> why Python's re module offers both match and search. Why not just
> >> use search with a beginning-of-string anchor? I find it particularly
> >> puzzling because I have this (possibly mistaken) idea that the
> >> Python design philosophy tends towards minimalism, a sort of Occam's
> >> razor, when it comes to language entities; i.e. having re.match
> >> along with re.search seems to me like an "unnecessary multiplication
> >> of entities". What am I missing?
>
> > It always seemed redundant to me also (notwithstanding Duncan Booth's
> > explanation of slight semantic differences). However, I find myself
> > using re.match much more often than re.search, so perhaps in this case
> > a "second obvious way" is justified.
>
> re.match is anchored at a certain position, whereas re.search isn't. The
> re module doesn't support Perl's \G anchor.
re.search is obstinately determined when it comes to flogging dead
horses:
C:\junk>\python26\python -mtimeit -s"import re" "re.match('xxx',
'y'*100)"
100000 loops, best of 3: 3.37 usec per loop
C:\junk>\python26\python -mtimeit -s"import re" "re.search('^xxx',
'y'*100)"
100000 loops, best of 3: 7.01 usec per loop
C:\junk>\python26\python -mtimeit -s"import re" "re.match('xxx',
'y'*1000)"
100000 loops, best of 3: 3.85 usec per loop
C:\junk>\python26\python -mtimeit -s"import re" "re.search('^xxx',
'y'*1000)"
10000 loops, best of 3: 37.9 usec per loop
C:\junk>
More information about the Python-list
mailing list