Python for Embedded Systems?

Cameron Laird claird at lairds.us
Sat Jul 15 16:35:46 EDT 2006


In article <n72dnUxdH493tSTZnZ2dnUVZ_oydnZ2d at comcast.com>,
Jack <nospam at invalid.com> wrote:
>Yes, I mean Lua, not Loa  :-p
>
>Lua is a nice language. Like you said, it doesn't have many libraries
>as Python does. Plus, it's still evolving and the libraries are changing.
>I found a few functions not working last time I tried kepler libraries.
>It's good for embedded systems though because of its small footprint.
>Extensions implemented in C makes it possible that the installation size
>doesn't blow up when new stuff is added, like in Python.
>
>But I still like Python better for its power and for the style of the 
>language
>itself. And I was hoping to find a Python implementation that bears the
>principles of Lua to make it suitable for embedded systems :)
>
>>> PHP may fit but I don't quite like the language. Anything else?
>>> Loa is small but it does not seem to be powerful enough.
>
>>You mean Lua ? Not powerful enough ? What do you mean by
>>that ? Lua is great IMHO. Sure it does not come with thousands
>>of libraries, but the language design is extremely clean, the
>>language constructs powerful and the footprint very small.
>
>>16kloc of C code can't hurt your embedded device can they ? ;)
>
>>Please tell us what kind of limitation you find in Lua ...
			.
			.
			.
PHP is about as bad a choice as there is for this domain.
Let's talk about it some other time.

The usual contestants are Forth, Lua, Tcl, and various Lisps.  
Python could play quite well at least in some situations, but
entirely no one has done much since 1.5.2 times (which doesn't
seem to me like a long time).

If you're to the point of sniffing at Lua's relative poverty
of libraries, you need to detail your requirements more pre-
cisely.  What's "small" and "embedded" to some people is a 
full-featured host to others.  Generally speaking, yes, Lua
is still advancing significantly, or, from a different per-
spective, it hasn't stabilized yet.  The point is that there's
necessarily no "Pareto optimizer" which is simultaneously
smallest, fastest, newest, most mature, most Unicode-aware,
most featureful, lowest-level, highest-level, ...  That's why
there's a point to the engineering we do here.



More information about the Python-list mailing list