Being a bit confused after hacking Python

[Wolfgang Draxinger]

Pete Shinners wrote:
> Wolfgang Draxinger wrote:
> 
> modules are only imported once.

That's good to know.

> I've never done this though, i don't believe it's hard, but 
> who knows?

When I hacked into Python I also went through the import stuff. However 
most is done by reading things from files. However there's also the 
possiblity to load binary modules from .so, .dll whatever. For scurity 
reasons only modules named in a game specific dependicies list cn be 
loaded. I solved this problem by hooking into __builtin__.__import__ and 
unpacking the required module to a local cache directory. That has also 
the advantage, that a package may contain source modules, that are then 
compiled on the fly and stored in the cache

>> 3rd:
> with rexec you can keep the user from doing many things. you can also 
> replace calls like "open" to map to your own virtual filesystem (which 
> might be useful). there's some pretty good docs on it, but i'm not sure 
> how you would set one up from the "c api".

My solution so far: I wrote a small python script setting up a rexec 
environment I can access from C and compiled that into a frozen code I 
included into my engines sources. Replacing the open function was a must 
and I scrached my head for nights on that problem. The solution via 
rexec is far better.

> there's always a chance someone could do something like "while 1:pass" 
> or try to allocate millions of objects.

Okay that is a problem, however if my engine has a small protection 
against this, when in user mode: If a event handler script takes longer 
than 5 seconds, then it isn't realtime and killed. Also scripting of 
prolonged processed, like a chain reaction in the game ( player ignites 
torch->5 seconds->burns rope->3 seconds->crate held by rope falls on 
enemy ;-) is done by shooting engine timers, which reside outside of the 
scripting system.

> as for reloading sys resetting stdout, why do you ever need to reload 
> it? if you just want to reset the stdout variables, just set sys.stdout 
> to sys.__stdout__. the __stdout__ is the "original" stdout object.

I just tried to understand the reload process out of interesst and ran 
about that confusing fact, that in the _PyInittab there is not 
initfunction entry for the builtin modules. In the case that on the 
console someone types ">>> import sys; reload(sys)", the console would 
be useless, since it has no longer access to Python std I/O. So long I'm 
catching the problem by hooking reload too, and checking for the modules 
I replaced.

-- 
+------------------------------------------------+
| +----------------+ WOLFGANG DRAXINGER          |
| | ,-.   DARKSTAR | lead programmer             |
| |(   ) +---------+ wdraxinger at darkstargames.de |
| | `-' / GAMES /                                |
| +----+''''''''     http://www.darkstargames.de |
+------------------------------------------------+