<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 23, 2013 at 4:34 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"><br><div class="gmail_quote"><div class="im">On Sat, Mar 23, 2013 at 4:14 PM, Gregory P. Smith <span dir="ltr"><<a href="mailto:greg@krypto.org" target="_blank">greg@krypto.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">keep=True defeats the purpose of a caching strategy.  An re.compile call within some code somewhere is typically not in a position to know if it is going to be called a lot.<div><br></div><div>I think the code, as things are now, with dynamic construction at runtime based on a simple test is the best of both worlds to avoid the more complicated cost of calling re.compile and going through its cache logic.  If the caching is ever is improved in the future to be faster, the code can arguably be simplified to use re.search or re.match directly and rely solely on the caching.</div>





<div><br></div><div>ie: don't change anything.</div><div><br></div></div></blockquote><div><br></div></div><div>Truth is people are currently doing caching themselves, by compiling and then keeping the compiled regex. Saying they're not in a position to know whether or not to do that isn't going to change that. Is it worthwhile having the regex library facilitate this manual caching? </div>

</div></blockquote><div><br></div><div style>In the absense of profiling numbers showing otherwise, i'd rather see all forms of manual caching like the conditional checks or a keep=True go away as it's dirty and encourages premature "optimization".</div>

<div style><br></div></div></div></div>