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