re compiled object result caching?

[Dan]

I find myself often using regular expressions in the following
pattern:

foo_re = re.compile(r"fo o(bar)")
# . . .
re_result = foo_re.search(l ine)
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"fo o(bar)")
# . . .
if foo_re.search(l ine):
foo_re.last_res ult().group(1)

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_condit ion and foo_re.search(l ine):
# . . .

With the current implementation I think you would either have to do
the search even if unlikely_condit ion 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?

-Dan

[Steve Holden]

Re: re compiled object result caching?

Dan wrote:

I find myself often using regular expressions in the following
pattern:
>
foo_re = re.compile(r"fo o(bar)")
# . . .
re_result = foo_re.search(l ine)
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"fo o(bar)")
# . . .
if foo_re.search(l ine):
foo_re.last_res ult().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_condit ion and foo_re.search(l ine):
# . . .
>
With the current implementation I think you would either have to do
the search even if unlikely_condit ion 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 -------------

[Dan Stromberg - Datallegro]

Re: re compiled object result caching?

On Wed, 29 Aug 2007 17:45:36 -0400, Steve Holden wrote:

Dan wrote:

>foo_re = re.compile(r"fo o(bar)")
># . . .
>if foo_re.search(l ine):
> foo_re.last_res ult().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've long felt that publicly accessible attributes probably should be
syntactic sugared to look like accessor methods, a bit like how __add__
ends up being + - so that if your attribute ever needs to become methods
(say, it started out life as a unidimensional thing, but later needs to
be a flattening of 3 dimensions or something), you won't necessarily need
to change depenent code.

But are methods a lot more expensive in python than referencing other
kinds of attributes?

[Marc 'BlackJack' Rintsch]

Re: re compiled object result caching?

On Wed, 29 Aug 2007 21:54:50 +0000, Dan Stromberg - Datallegro wrote:

I've long felt that publicly accessible attributes probably should be
syntactic sugared to look like accessor methods, a bit like how __add__
ends up being + - so that if your attribute ever needs to become methods
(say, it started out life as a unidimensional thing, but later needs to
be a flattening of 3 dimensions or something), you won't necessarily need
to change depenent code.

Maybe you should read about the `property()` function.

Ciao,
Marc 'BlackJack' Rintsch

[Steve Holden]

Re: re compiled object result caching?

Dan Stromberg - Datallegro wrote:

On Wed, 29 Aug 2007 17:45:36 -0400, Steve Holden wrote:
>

>Dan wrote:

>>foo_re = re.compile(r"fo o(bar)")
>># . . .
>>if foo_re.search(l ine):
>> foo_re.last_res ult().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've long felt that publicly accessible attributes probably should be
syntactic sugared to look like accessor methods, a bit like how __add__
ends up being + - so that if your attribute ever needs to become methods
(say, it started out life as a unidimensional thing, but later needs to
be a flattening of 3 dimensions or something), you won't necessarily need
to change depenent code.
>
But are methods a lot more expensive in python than referencing other
kinds of attributes?
>

Well, given that they are procedure calls, yes. There's also other magic
over and above that.

The property() function is a way of making what appear to be attribute
accesses become method calls. Your intuition is taking you the wrong
way: if you need an accessor method then just turn the normal attribute
into a property. Given that mechanism, your wish to use accessor methods
is definitely anti-pythonic.

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 -------------