[Python-Dev] Minipython

[Milan Krcmar]

Thank you people. I'm going to try to strip unneeded things and let you
know the result.

Along with running Python on an embedded system, I am considering two
more things. Suppose the system to be a small Linux router, which, after
the kernel starts, merely configures lots of parameters of the kernel
and then runs some daemons for gathering statistics and allowing remote
control of the host.

Python helps mainly in the startup phase of configuring kernel according
to a human-readable confgiuration files. This has been solved by shell
scripts. Python is not as suitable for running external processes and
process pipes as a shell, but I'd like to write a module (at least)
helping him in the sense of scsh (a "Scheme shell",
http://www.scsh.net).

A more advanced solution is to replace system's init (/sbin/init) by
Python. It should even speed the startup up as it will not need to run
shell many times. To avoid running another processes, I want to "port
them" to Python. Processes for kernel configuration, like iproute2,
iptables etc. are often built above its own library, which can be used as
a start point. (Yes, it does matter, at startup, routers run such processes
hundreds times).

Milan

On Sun, Sep 24, 2006 at 06:49:34AM +0200, "Martin v. Löwis" wrote:
> Milan Krcmar schrieb:
> > Can you give me any information to start with? I would prefer stripping
> > current version of Python rather than returning to a years-old (but
> > smaller) version and remembering what of the new syntax/functionality to
> > avoid.
> 
> I would start with dropping support for dynamic loading of extension
> modules, and link all necessary modules statically.
> 
> Then, do what Michael Hudson says: find out what is taking up space.
> 
> size */*.o|sort -n
> 
> should give a good starting point; on my system, I get
> 
> [...]
>   29356    1416     156   30928    78d0 Objects/classobject.o
>   30663       0       0   30663    77c7 Objects/unicodectype.o
>   33530     480     536   34546    86f2 Python/Python-ast.o
>   33624    1792     616   36032    8cc0 Objects/longobject.o
>   36603      16     288   36907    902b Python/ceval.o
>   36710    2532       0   39242    994a Modules/_sre.o
>   39169    9473    1032   49674    c20a Objects/stringobject.o
>   52965       0      36   53001    cf09 Python/compile.o
>   66197    4592     436   71225   11639 Objects/typeobject.o
>   74111    9779    1160   85050   14c3a Objects/unicodeobject.o
> 
> Michael already mentioned you can drop unicodeobject if you want
> to. compile.o would also offer savings, but stripping it might
> not be easy. Dropping _sre is quite easy. If you manage to
> drop compile.o, then dropping Python-ast.o (along with the
> rest of the compiler) should also be possible.
> unicodectype will go away if the Unicode type goes, but can
> probably be removed separately. And so on.
> 
> When you come to a solution that satisfies your needs,
> don't forget to document it somewhere.
> 
> Regards,
> Martin