On Thu, Feb 9, 2012 at 13:43, PJ Eby <pje at telecommunity.com> wrote: > > On Feb 9, 2012 9:58 AM, "Brett Cannon" <brett at python.org> wrote: > > This actually depends on the type of ImportError. My current solution > actually would trigger an ImportError at the import statement if no finder > could locate the module. But if some ImportError was raised because of some > other issue during load then that would come up at first use. > > That's not really a lazy import then, or at least not as lazy as what > Mercurial or PEAK use for general lazy importing. If you have a lot of > them, that module-finding time really adds up. > > 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. > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120209/824e21b8/attachment.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