<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 23, 2013 at 4:03 PM, Bruce Leban <span dir="ltr"><<a href="mailto:bruce@leapyear.org" target="_blank">bruce@leapyear.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To summarize:<div><br></div><div>- compiling regexes is slow so applications frequently compute it once and save it</div>

<div>- compiling all the regexes at startup slows down startup for regexes that may never be used</div>

<div>- a common pattern is to compute once at time of use and it would be nice to optimize this pattern</div><div>- the regex library has a cache feature which means that frequently it will be optimized automatically</div>



<div>- however, there's no guarantee that the regex you care about won't fall out of the cache.</div><div><br></div><div>I think this addresses all the issues better than compute_lazy:</div><div><br></div><div>re.compile(r'...', keep=True)</div>



<div><br></div><div>When keep=True is specified, the regex library keeps the cached value for the lifetime of the process. The regex is computed only once on first use and you don't need to create a place to store it. Furthermore, if you use the same regex in more than one place, once with keep=True, the other uses will automatically be optimized.</div>

</blockquote><div><br><br></div><div>Nice summary. The real problem is, I think, that many developers are not aware of the default caching done by the re module. I have a hunch that if this was better known, fewer manual optimization attempts would spring up.<br>

<br></div><div>How about examining what the size of that re cache is, and how much memory it typically occupies. Perhaps this cache can be changed to fit more regexes?<br><br></div><div>Eli<br></div><div><br> </div></div>

</div></div>