Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #106500
| From | Chris Angelico <rosuav@gmail.com> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: module alias in import statement |
| Date | 2016-04-05 17:47 +1000 |
| Message-ID | <mailman.57.1459842452.32530.python-list@python.org> (permalink) |
| References | (4 earlier) <CAPTjJmrskhvZBo5jbiDu4HGpp+YQ2u3sBj-ZFp3KcMv9e5LHyA@mail.gmail.com> <mailman.52.1459830198.32530.python-list@python.org> <b707ce3a-6e9e-45dd-9f4d-2cc6c8d197a6@googlegroups.com> <570368c2$0$1533$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmp5cNi18VOqbfxmcWQLij1O9SGVE_Rcw6mosh4+XzFiew@mail.gmail.com> |
On Tue, Apr 5, 2016 at 5:26 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: >>> sys.modules isn't really a cache in that sense, though. The "hard >>> problem" of cache invalidation comes from the fundamental assumption >>> that a cache hit should be semantically identical to a cache miss; >> >> Following looks like a cache miss to me (certainly did to the OP): >> >> On Monday, April 4, 2016 at 9:01:41 PM UTC+5:30, ast wrote: >>> hello >>> >>> >>> import tkinter as tk >>> >>> import tk.ttk as ttk >>> >>> Traceback (most recent call last): >>> File "<pyshell#3>", line 1, in <module> >>> import tk.ttk as ttk >>> ImportError: No module named 'tk' > > > But that *miss* isn't cached -- if the OP then created a package called "tk" > with a submodule called "ttk", and then re-ran the `import tk.ttk as ttk` > line, the import subsystem would have picked up the newly created package > and imported it. > > I think that's the point Chris was trying to make. Not quite; that was a separate point (that negative results aren't cached). A cache miss is when the cache doesn't have something, and Python goes to the next source (in this case, searching the file system). The end result should be the same in either case (you get a module object), but in Python, a cache miss results in *actual code execution*. Granted, you often still won't *see* any difference (your typical module just quietly defines a bunch of stuff), but there's still a significant semantic difference; consider what happens when you type "import this as that" followed by "import this". The second one is a cache hit, and it's fundamentally different in function. Cache invalidation is all about knowing when you should *ignore* the cached entry and go back to the file system. Python will never do this, because the semantics are defined very differently. ChrisA
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
module alias in import statement "ast" <nomail@com.invalid> - 2016-04-04 17:31 +0200
Re: module alias in import statement Ned Batchelder <ned@nedbatchelder.com> - 2016-04-04 08:59 -0700
Re: module alias in import statement Steven D'Aprano <steve@pearwood.info> - 2016-04-05 02:15 +1000
Re: module alias in import statement Terry Reedy <tjreedy@udel.edu> - 2016-04-04 16:46 -0400
Re: module alias in import statement Rustom Mody <rustompmody@gmail.com> - 2016-04-04 21:08 -0700
Re: module alias in import statement Chris Angelico <rosuav@gmail.com> - 2016-04-05 14:23 +1000
Re: module alias in import statement Rustom Mody <rustompmody@gmail.com> - 2016-04-04 21:27 -0700
Re: module alias in import statement Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-04-05 17:26 +1000
Re: module alias in import statement Chris Angelico <rosuav@gmail.com> - 2016-04-05 17:47 +1000
csiph-web