#include equivalent

[Kragen Sitaker]

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]