status of Programming by Contract (PEP 316)?

[Roy Smith]

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 
pressure.