Best Scripting Language for Embedded Work?

David T. Ashley dashley at gmail.com
Thu Jul 11 21:14:35 EDT 2013


On Tue, 09 Jul 2013 21:44:48 -0400, Dave Angel <davea at davea.name>
wrote:

>On 07/09/2013 09:29 PM, David T. Ashley wrote:
>> We develop embedded software for 32-bit micros using Windows as the
>> development platform.
>>
>> We are seeking a general purpose scripting language to automate
>> certain tasks, like cleaning out certain directories of certain types
>> of files in preparation for ZIP'ing, generating certain source files
>> automatically, etc.
>>
>> Selection criteria:
>>
>> a)Should be able to compile the script interpreter as a monolithic
>> executable (no .DLL dependencies, etc.) for easy versioning and
>> distribution of the script interpreter.
>
>Oh, I thought you were going to run this on Windows.  You're just 
>developing it on Windows, and you want to cross-compile to target some 
>other platform?  Which?

Sorry, I wasn't very complete.

The scripts would run on Windows 7 only, but because they may generate
part of the source code for the embedded system, we have to be careful
about versioning the interpreter, and a monolithic executable makes
that simpler.

>>  (Note that I'm not asking
>> that the script be a single executable, just the interpreter.  To run
>> a script you'd need both the script and the interpreter.  The script
>> would be a text file, and the interpreter would be a single .EXE.)
>
>If you're also constraining your "program" to a single text file, you 
>don't want Python.  It uses modules, imported from your script to do 
>much of the work.
>
>>
>> b)Should be extensible, in that one could add commands or library
>> functions to the script interpreter in C (for efficiency), and the
>> whole script interpreter could again consist of a single executable
>> with no other dependencies.  (Note that I'm not asking that the script
>> be a single executable, just the interpreter.  To run a script you'd
>> need both the script and the interpreter.  The script would be a text
>> file, and the interpreter would be a single .EXE.)
>
>And that's supposed to HELP efficiency??

Did I ever claim I wanted efficiency?

>> c)Should be able to spawn compilers and capture the output, do file
>> I/O, and all the other minor expected stuff.
>>
>> d)Graphical capability would be nice.
>>
>> I know that Tcl/Tk would do all of the above,

I was able to do this with Tcl/Tk years ago.

>I doubt it.
>
>> but what about Python?
>> Any other alternatives?



More information about the Python-list mailing list