Q: Size of embedded Python code?

Amit Patel

unread,

Feb 19, 1998, 3:00:00 AM2/19/98

to

I think embedding Python in my game would be really neat. I just
don't want it to increase the size of my executable too much. My
executable is around 300k, and the Python15.DLL file on my system is
around 500k -- so that's way too big to embed. :(

Does anyone have information about the size of Python, when embedded?

1. Can I embed the VM but not the compiler?
(This way, I could distribute .pyc files, and anyone who
wants to mess with the system would have to have Python
installed.)

2. How much is taken up by "standard" modules? How many of
these modules are absolutely needed? I'd imagine 're'
would be quite large...

3. Can I conditionally compile certain features of Python?
For example, if I don't do any I/O then I may not want
to embed open(), file objects, the % operator on strings,
and the `print' command...

I also may not want to have exec and eval.

4. Can I omit built-in types such as complex numbers and
arbitrary precision integers?

I think Python may be too large for my needs, but a subset of Python
may be useful. I don't really know enough about embedding to know
whether I should work on embedding Python or if I should create my own
tiny language...

Thanks for any suggestions!

- Amit

Andrew Kuchling

unread,

Feb 20, 1998, 3:00:00 AM2/20/98

to

Amit Patel writes:
>2. How much is taken up by "standard" modules? How many of
> these modules are absolutely needed? I'd imagine 're'
> would be quite large...

Absolutely needed for what? Presumably your game's scripting
won't be opening socket connections or parsing RFC822 e-mail messages,
so there are lots of built-in and library modules you can discard. I
find that using a blank Modules/Setup file reduces the python
executables size 50% on Solaris, so perhaps you'll get comparable
numbers. There's no official Python standard, so no one's going to
sue you for leaving things out.

>3. Can I conditionally compile certain features of Python?
> For example, if I don't do any I/O then I may not want
> to embed open(), file objects, the % operator on strings,
> and the `print' command...
>
> I also may not want to have exec and eval.

You could patch Python/bltinmodule.c and #ifdef out any
functions you don't want, but I don't think it would shrink the code
size very much. (It would, however, mean you needn't worry about
scripts opening files.) To gain much from removing exec(), you'd have
to remove the parser & bytecode compiler, and that's probably
complicated, as would removing file objects. (How are you going to
debug code without 'print', anyway?)

To remove long integers, or the % operator, you'd have to
modify the parser, changing the grammar for the language. Complex
numbers are a special case; it looks like you can just #define
WITHOUT_COMPLEX when compiling Python to remove them. In general,
it'll be simple to remove modules that aren't useful, but hacking the
grammar would be a lot of pain for little gain. It's probably best to
leave the language itself alone, and just dump useless modules.

A.M. Kuchling http://starship.skyport.net/crew/amk/
Copying all or parts of a program is as natural to a programmer as
breathing, and as productive. It ought to be as free.
-- Richard Stallman

Lyn A Headley

unread,

Feb 21, 1998, 3:00:00 AM2/21/98

to

If you're looking for a really small and really cool extension
language, have a look at lua:

http://www.tecgraf.puc-rio.br/lua/

--
Lyn Headley
remove the word "bogus" from my address for the real one.