471,330 Members | 1,933 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,330 software developers and data experts.

re compiled object result caching?

Dan

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)

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?

-Dan

Aug 29 '07 #1
4 912
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 -------------

Aug 29 '07 #2
On Wed, 29 Aug 2007 17:45:36 -0400, Steve Holden wrote:
Dan wrote:
>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'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?

Aug 29 '07 #3
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
Aug 29 '07 #4
Dan Stromberg - Datallegro wrote:
On Wed, 29 Aug 2007 17:45:36 -0400, Steve Holden wrote:
>Dan wrote:
>>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'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 -------------

Aug 29 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.