Showing content from http://mail.python.org/pipermail/python-dev/attachments/20120209/f530728a/attachment.html below:
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
On 2/9/2012 11:53 AM, Mike Meyer wrote:
<blockquote cite="mid:20120209115302.2ce94321@bhuda.mired.org"
type="cite">
<pre wrap="">On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannon <a class="moz-txt-link-rfc2396E" href="mailto:brett@python.org"><brett@python.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, Feb 9, 2012 at 13:43, PJ Eby <a class="moz-txt-link-rfc2396E" href="mailto:pje@telecommunity.com"><pje@telecommunity.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Again, the goal is fast startup of command-line tools that only use a
small subset of the overall framework; doing disk access for lazy imports
goes against that goal.
</pre>
</blockquote>
<pre wrap="">Depends if you consider stat calls the overhead vs. the actual disk
read/write to load the data. Anyway, this is going to lead down to a
discussion/argument over design parameters which I'm not up to having since
I'm not actively working on a lazy loader for the stdlib right now.
</pre>
</blockquote>
<pre wrap="">
For those of you not watching -ideas, or ignoring the "Python TIOBE
-3%" discussion, this would seem to be relevant to any discussion of
reworking the import mechanism:
<a class="moz-txt-link-freetext" href="http://mail.scipy.org/pipermail/numpy-discussion/2012-January/059801.html">http://mail.scipy.org/pipermail/numpy-discussion/2012-January/059801.html</a>
<mike
</pre>
</blockquote>
<br>
So what is the implication here? That building a cache of module
locations (cleared when a new module is installed) would be more
effective than optimizing the search for modules on every invocation
of Python?<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