A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/1999-November/001165.html below:

[Python-Dev] RE: [String-SIG] Re: regexp performance

[Python-Dev] RE: [String-SIG] Re: regexp performanceFredrik Lundh fredrik@pythonware.com
Thu, 11 Nov 1999 09:06:04 +0100
Tim Peters <tim_one@email.msn.com> wrote:
> > The problem is that PCRE never builds a parse tree, and
> > parse trees are easy to analyse recursively.  Instead, PCRE's
> > functions actually look at the compiled byte codes (for example, look
> > at find_firstchar or is_anchored in pypcre.c), but this makes analysis
> > functions hard to write, and rearranging the code near-impossible.
> 
> This is wonderfully & ironically Pythonic.  That is, the Python compiler
> itself goes straight to byte code, and the optimization that's done works at
> the latter low level.

yeah, but by some reason, people (including GvR) expect a
regular expression machinery to be more optimized than the
language interpreter ;-)

</F>




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4