About a year ago, I developped micropython within a few hours worth of work.
The idea was to bootstrap the python build process with python itself,
and get rid of all the autoconf/config stuff.
micropython is therefore a 'minimal python' in the sense that it only
contains the minimal required to execute regular python code, including
the base os functions.
micropython is a python interpreter build as a single executable using
the smallest set of source files covering only the base built-in types
(no complex numbers, cobjects built-in....) from the python distribution
(modulo some #ifdef), and dropping the dynamic C module loading.
As result, micro python builds with no configuration at all, from a
minimal makefile running under on either VC++ (nmake) or posix.
The idea is that, once build, micropython be used to execute python
configuration scripts (in replacement to the config.in stuff) to
generate the full-fledged (platform-specific) makefile.
The procedure has been successful. I did not go further just because I
changed job and got a newborn daughter requesting my attention and that
I get decent money in the house (which is something I have not been
ablel to conciliate with Python, lately)...
I'm not really putting any development time on these things, but if
anybody has questions, I'll answer them.
The source code was branched from python 2.1.1, and is available under
the 'micro' branch' from the 'pythonx/ directory of the CVS distribution
of JPE (jpe.sf.net).
The bootstrapping Makefile is:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jpe/pythonx/Python/Micro/Att…
The thrust beyond micropython (asides from the philosophical discussions
concerning the lean development) was to propose an alternate way to
autoconf/config, to bootstrap the python build process.
[For the curious: The development of the shared library facility in
pythonx required ediding and fixing the autoconf/config files, something
I sweared I'd never do again.
After developping it, I've been convinced that micropython should be
used in replacement to autoconf/config for generating the
plateform-specific makefiles for all platforms (including win32), using
the same python config script.]
Cheers,
Frederic G.
>
>
>From: holger krekel <pyth(a)trillke.net>
>
>We announce a mailinglist dedicated to developing
>a "Minimal Python" version. Minimal means that
>we want to have a very small C-core and as much
>as possible (re)implemented in python itself. This
>includes (parts of) the VM-Code.
>
>From: Guido van Rossum <guido(a)python.org>
>Way cool.
>
>
+1
I've been thinking of proposing a very similar thing - though I was
thinking "Python in Python" which suggest all sorts of interesting logo
ideas. :-)
>We are very interested in learning about and
>integrating prior art. And in hearing any
>doubtful or reinforcing opinions. Expertise
>is welcomed in all areas.
>
The Squeak Smalltalk implementation is interesting & relevant:
http://www.squeak.org/features/vm.html
The Squeak VM is written in a subset of Smalltalk ("Slang", different
from "S-lang") that can be translated directly to C. This core provides
the interpreter for the rest of the language, allowing the entire system
to be very portable, and it facilitates development in many ways - you
get to work on the core while working in your favorite language, you get
to use all your favorite tools, etc. Plus I expect the translatable
subset provides a solid, simple basis for integrating external code.
I think a similar approach would be very useful in Minimal Python (...
in Python), probably adopting ideas from Psyco
http://psyco.sourceforge.net/ and/or Pyrex
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/ as the foundation
for the "compilable subset".
This would also provide a nice basis for a Jython implementation...
Can-I-play-with-it-yet?-ly y'rs,
kb
