OOgtech

I’ve just installed Python and Panda3D, then realised that… …Panda3D installs it’s own (outdated) Python release.

This may be the first of a small series of Python/Panda3D tutorials. As it turns it will be a ‘peer to peer’ tutorial, since I’m learning both Python and Panda3D as I go.

I won’t assume that you can’t write a computer program or don’t understand 3D. So I’m afraid this won’t be suitable for complete newbies. More like a crash course.

OK, after running a couple of examples, my first question was:

How does Python find imported modules?

Yes, there is a ‘classpath’:

1. Current directory, ie, the target directory when starting our python app.
2. PYTHONPATH environment variable
3. .pth files; .pth files are used to add locations to the search path – if a pth files is on the search path (in an already known location), then it is read and all files listed there are also added to the path.
   This is convenient – say we have a foo/script.py script, then all we need to import custom modules is define a foo/import.pth file pointing at our custom module definition files.
4. sys.path variable. At runtime, we can reach (and edit) this by importing sys, and print the current classpath using print sys.path.
   Changing sys.path at runtime allows dynamically adding locations to the classpath.

Most of this is  documented. The best of it,  .pth files, is apparently still undocumented.

I’m just running the sample programs so far. My guess is that Panda3D is adding its eggs to PYTHONPATH.

Import statements

Python uses both import X and import X from Y statements. The equivalent of the java import is import X from Y (I found a nice article detailing python imports)

Why bother?

Sure, if you install P3D the way I did, you don’t really need to know about sys.path to get started with the sample programs. But then, until we know how the path works, we can’t release software. Let’s be agile. We don’t want to wait another year until we release our first P3D app.