re compiled object result caching?

Steve Holden steve at holdenweb.com
Wed Aug 29 17:45:36 EDT 2007


Dan wrote:
> I find myself often using regular expressions in the following
> pattern:
> 
> foo_re = re.compile(r"foo(bar)")
> # . . .
> re_result = foo_re.search(line)
> if re_result:
>     bar = re_result.group(1)
>     # . . .
> 
> But, I keep thinking this is awkward, and I would kind of like to have
> the re object to cache its result; along the lines of:
> 
> foo_re = re.compile(r"foo(bar)")
> # . . .
> if foo_re.search(line):
>     foo_re.last_result().group(1)
> 
If you wanted to implement this I don't really see why a method call is 
necessary. It would surely only need to be a simple attribute?

Of course you then introduce the possibility that someone will reference 
if before using the RE in a search, plus it still requires separate 
storage if you want the ability to use the same RE for two different 
matches and compare the match results.

> I realize I could do this with a wrapper object (I'm not sure if I can
> subclass the re object..), but I was wondering what the community
> thought of this. Good idea? Bad? Would it be difficult to add to the
> standard re module? The only real downside I can think of is thread
> safety. The other practical benefit I can think of is situations like
> the following:
> 
> if unlikely_condition and foo_re.search(line):
>    # . . .
> 
> With the current implementation I think you would either have to do
> the search even if unlikely_condition is False, or you would have to
> do an annoying nested if. Is there another way to achieve this that
> I'm not thinking of?
> 
I see absolutely no reason why you can't create your own module with a 
compile function that produces an extended_RE object by compiling the RE 
passed as an argument and saving the compiled result. It can then 
delegate most method calls to the compiled RE, but extend certain of its 
methods to provide the behavior that you want.

Personally I think it's anti-Pythonic to abhor

matchobj = pat.match(...)

You throw some clarity out just for the sake of making the "no match" 
case a teeny bit faster and a minute amount more readable. But others' 
opinions may differ.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------




More information about the Python-list mailing list