Embedding Python the extreme way

Wolfgang Draxinger wdraxinger at darkstargames.de
Wed Jul 10 10:18:55 EDT 2002


Michael Hudson wrote:
> Wolfgang Draxinger <wdraxinger at darkstargames.de> writes:
> 
> 
>>Michael Hudson wrote:
>>
>>
>>>To me these sentences contradict each other.  So I must be missing
>>>something...
>>
>>I want not to add a statically linkes python.lib to my linkage
> 
> 
> Why not?  Do you mean you don't want to use the distributed python.lib?

Yeah, right. My fault, I meant the distributed python.lib.

> No, you don't: far too much of the internals depends on getting things
> out of the sys module.  You might be able to hide things from the
> scripts that you execute, but that's a different problem, surely?
I see.

> OK, so I think a better (read: easier) strategy might be to /hide/
> these objects, not /remove/ them.

How can I do that? My initial idea was to modify bltinmodule.c to do 
things I want. What I definitly don't want, is to call Py_Initialize() 
and then replace the original modules with my own. I'd appreciate it, if 
it would be possible to modify the sources.

> Because there are probably easier ways of acheiving what you want;
> executing "engine object scripts" is a heavily custimized environment
> is almost certain to be more straightforward than heavily customizing
> the interpreter, and sounds to me as if it will do the job.

At the moment it works, but the performance is lousy, not because Python 
is slow, but I had to do a lot of workarounds.

Ok:
To shorten the discussion:
My situatuin is the following:
I removed all external modules avilabe to python, so that I only have 
acces to the builtin's and the one's provided by the engine.

Now I want to know: which modules are not really neccesary for the 
_interpreter_ and the interactive mode to work at all. When I want to 
start that reduced environment I want, that I can perform nothing very 
usefull. And from this situation I want to provide the environment I need.

At the moment my builtins list looks like the following. I've read the 
doc-string. Those modules, where I think, that I don't need them at all 
I marked with a 'X'. Things which shouldn't be touched by the Scripts 
are marked with a 'T'. Things to be replaced are 'R'.

Oh, another important thing:
Threads are handled by the engine. All scripts should run in a single 
thread. So python thread support must be removed.

__builtin__
_codecs
_hotshot
_locale
_weakref
array
audioop X
binascii T
cPickle T
cStringIO T
cmath
errno T
exceptions T
gc T
imageop X
imp T
marshal T
math
md5 X
msvcrt X
new T
nt X
operator
pcre T
regex X
rgbimg X
rotor
sha T
signal T
strop
struct T
sys R
thread X
time R
xreadlines X
xxsubtype X

Hope that helps. If you need a short data flow diagram of the engine to 
understand why these needs are there I'll post it here.

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




More information about the Python-list mailing list