Why re.match()?

[MRAB]

kj wrote:
> In <025db0a6$0$20657$c3e8da3 at news.astraweb.com> Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
> 
>> On Thu, 02 Jul 2009 11:19:40 +0000, kj wrote:
> 
>>> If the concern is efficiency for such cases, then simply implement
>>> optional offset and length parameters for re.search(), to specify any
>>> arbitrary substring to apply the search to.  To have a special-case
>>> re.match() method in addition to a general re.search() method is
>>> antithetical to language minimalism, and plain-old bizarre.  Maybe
>>> there's a really good reason for it, but it has not been mentioned yet.
> 
>> There is, and it has.
> 
> I "misspoke" earlier.  I should have written "I'm *sure* there's
> a really good reason for it."  And I think no one in this thread
> (myself included, of course) has a clue of what it is.  I miss the
> days when Guido still posted to comp.lang.python.  He'd know. 
> 
> Regarding the "practicality beats purity" line, it's hard to think
> of a better motto for *Perl*, with all its practicality-oriented
> special doodads.  (And yes, I know where the "practicality beats
> purity" line comes from.)  Even *Perl* does not have a special
> syntax for the task that re.match is supposedly tailor-made for,
> according to the replies I've received.  Given that it is so trivial
> to implement all of re.match's functionality with only one additional
> optional parameter for re.search (i.e. pos), it is absurd to claim
> that re.match is necessary for the sake of this special functionality.
> The justification for re.match must be elsewhere.
> 
> But thanks for letting me know that I'm entitled to my opinion.
> That's a huge relief.
> 
As I wrote, re.match anchors the match whereas re.search doesn't. An
alternative would have been to implement Perl's \G anchor, but I believe
that that was invented after the re module was written.