In article <En7y6.1222$p5.4633 at news1.rivrw1.nsw.optushome.com.au>,
deadmeat <root@[127.0.0.1]> wrote:
>> Yes, but you shouldn't use it for that --- instead, use import.
>
>Doesn't import only work for modules that live in sys.path/pythonpath?
>execfile allows one to specify exactly what file to use, which is good for
>keeping projects and the libraries they use separate (a lot of scripting
>languages seem to have this thing for dumping everything into the system
>library paths...)
Yeah, but there are problems with execfile():
- it puts all the stuff in that file in *your* namespace (not a separate one)
- circular execfile()s will hang your program and eventually crash
either your interpreter or your computer
- execfile()ing the same file from two different modules generates two
copies of everything in that file. This is rarely what you want.
- It takes more time (potentially *much* more time)
- it takes more space (potentially *much* more space)
- it breaks objects that try to determine whether other objects are
of the same class as themselves (although You Shouldn't Do This, I
haven't found a way to avoid it in some of the symbolic hacking
I've done)
- and it breaks any modules that try to maintain module state (like
asyncore).
So don't use execfile() instead of import.
Still, I find the whole import-can't-find-my-module thing to be
painful. One day I'll figure out how to set pythonpath to include the
directory a script was loaded from...
--
<kragen at pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Perilous to all of us are the devices of an art deeper than we possess
ourselves.
-- Gandalf the White [J.R.R. Tolkien, "The Two Towers", Bk 3, Ch. XI]
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