status of Programming by Contract (PEP 316)?
roy at panix.com
Fri Aug 31 07:15:04 CEST 2007
Carl Banks <pavlovevidence at gmail.com> wrote:
> Python really isn't suitable for in-flight controls for various
> reasons, and mission critical concerns is a minor one (systems with
> less underlying complexity tend to have fewer failure modes). But
> mostly it's raw throughput: Python is just too slow. Flight control
> computers have to be powerful enough make a ton of mathematical
> calculations in a matter of milliseconds, and under strict weight and
> power constraints. The cost of running 100 times slower than optimal
> is just too high.
I'm not convinced that's true for all avionics uses. Certainly, if you're
doing the fly-by-wire stability control system for a dynamically unstable
airframe, you need a lot of compute power and guaranteed real-time response
(recovery from a VMC rollover is no time for garbage collection). But, not
everything in an airplane is like that.
Take something relatively complicated like a GPS. The basic receiver is
pretty compute intensive, but that's likely to be a dedicated chip. Most
of the functionality in the box, however, requires a lot less horsepower.
You need to handle user input (i.e. keep up a scan on maybe 20 keys), and
update a low-res display (320 x 240 x 8 bit color is typical) with text or
cartoon graphics. There are certain real-time calculations which need to
be done, such as time, distance, and bearing to the next waypoint, but
these are typically updated a few times a second.
Like most things that use Python (or TCL, or Ruby, or ...), I would expect
that most of the low-level stuff would be done in something like C and
Python would be used for the glue code and things where there's no time
More information about the Python-list