Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171001/adbc994a/attachment-0001.html below:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#330033" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/1/2017 7:34 PM, Nathaniel Smith
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPJVwBkVzDq7g0-X0e+J=xm6LrH41SpkFdQr97DP1y01PikC7w@mail.gmail.com">
<blockquote type="cite" style="color: #000000;">
<pre wrap="">Another major slowness comes from compiling regular expression.
I think we can increase cache size of `re.compile` and use ondemand cached
compiling (e.g. `re.match()`),
instead of "compile at import time" in many modules.
</pre>
</blockquote>
<pre wrap="">In principle re.compile() itself could be made lazy -- return a
regular exception object that just holds the string, and then compiles
and caches it the first time it's used. Might be tricky to do in a
backwards compatibility way if it moves detection of invalid regexes
from compile time to use time, but it could be an opt-in flag.
</pre>
</blockquote>
Would be interesting to know how many of the in-module, compile time
re.compile calls use dynamic values, versus string constants. Seems
like string constant parameters to re.compile calls could be moved
to on-first-use compiling without significant backwards
incompatibility impact if there is an adequate test suite... and if
there isn't an adequate test suite, should we care about the
deferred detection?<br>
</body>
</html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4