kj wrote:
In <025db0a6$0$20657$c3e8...@news.astraweb.com> Steven D'Aprano
<st...@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.
--
http://mail.python.org/mailman/listinfo/python-list
