How to statically bind modules written in Python

[Travis Nixon]

Ok, after quite a lot of trouble, I've got a Windows version compiling that doesn't require the python dll in any way shape or form.

I've also figured out how to statically add C based modules, so they can be imported on a system that doesn't contain anything other than the statically linked python.exe.  Obviously, I won't be able to import outside modules from dlls or .py files, but I'm ok with that.

Now, where I'm running into a problem is that there are going to be some .py files that I need to be able to import, but I can't for the life of me figure out how to bind them statically, so they're available for scripts run by my statically linked python.exe.  Eventually, this is going to be the base for using python embedded into a project that doesn't have (as far as I know) support for any type of dynamic linking.

Any suggestions on how to approach this?  Basically what I want is to have something along the lines of a module named staticmodule.py, and have that available through the normal import statement, without it actually going out to disk to look for it.

A couple solutions I've considered:

Solution 1: Rewriting the necessary modules in C, and adding them to the library.  Obviously, for any new modules I could probably do this, although it would very possibly end up being more work than I really wanted to do (which is one of the reasons I'm trying to do this in the first place, to make LESS work).  But there are some .py files in the standard distribution that I'd like to include as well, and I'm going by the (possibly faulty) assumption that if they were easy to move to C, it would already have been done. :)

Solution 2: I read a post from somebody suggesting throwing the python modules through freeze, and then copying the generated C code.  First of all, I'm having trouble getting freeze to work at all on windows, and even when/if I do get it working, this also is more work than I really want to do.  And it's work that has to be done by hand, as opposed to work that can be done by a makefile.

Solution 3: I just thought of this, but it probably would be possible to include the .py files (or rather the .pyc files) in the resources, and rewrite the python's import to grab them from there instead of going to disk.  The major problem here is that our final platform is not going to be windows.  I suppose I could do something similar though, with a file that's loaded into memory at startup, and then do the same sort of modifications to import to search there instead.  This is actually a fairly workable option, but it's still just not as clean and elegant as simply being able to somehow statically bind the .py module to the executable itself.  (which as I'm writing this I'm realizing is probably impossible anyway)

By the way, the reason I don't want to just have them loaded from disk on demand is that the eventual target is a game console, and I don't want to have to hit the disk during the game for a python script that's just being imported.  I'd prefer to load them all up front (since they should be fairly small), and provide import access to them that way.

Anyway, I seem to have mosty answered my own question, but if anybody has any input on something I'm maybe missing, sharing would be greatly appreciated. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20001018/f3445e0c/attachment.html>