Does Python really follow its philosophy of "Readability counts"?

Bruno Desthuilliers bdesth.quelquechose at free.quelquepart.fr
Sun Jan 18 16:20:54 CET 2009


Russ P. a écrit :
> On Jan 17, 1:43 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>> Bruno Desthuilliers <bdesth.quelquech... at free.quelquepart.fr> writes:
>>> Once again, there's quite a lot to learn from
>>> the story of Ariane 5.
>> Do you know what actually happened with Ariane 5?  The failure was
>> because "smart" humans overrode the language enforced protection by
>> casting a floating point number down to a 16-bit integer, which worked
>> ok in Ariane 4, but failed with an overflow on Ariane 5 where bigger
> 
> So this turns out to be an example of a failure due, not to the
> *rigidity* of Ada, but to its *permissiveness* in allowing such a
> cast.

Nope. This is an example of failure due to the *human* part of the 
process - this happened because of a lack of testing / QA, not because 
of a language feature or misfeature.

(snip)

>> This is one thing that Python gets right, automatically using bignums
>> rather than allowing int overflow.  In that sense, Python has more
>> enforced protection than Ada.
> 
> True, but Ada does not have the luxury of just using doubles and
> "bignums" everywhere, because it needs to work on cheap processors
> too.   But perhaps it could somehow be configured to do so by the user
> if sufficiently powerful computers are being used.

Here the error was *not* to disable the overflow error checking (in the 
context of Ariane 4), but to reuse the module as-is in another context.

As I already stated, no technology can protect us from this kind of 
error. Ask yourself why this module was reused as-is, instead of going 
thru the whole specs / tests / QA process again, and *perhaps* you'll 
start to understand why I say that language-enforced access restrictions 
are the wrong solution to a real problem.




More information about the Python-list mailing list