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

[Carl Banks]

On Jan 14, 1:40 am, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> On Tue, 13 Jan 2009 20:17:08 -0800, Carl Banks wrote:
> > On Jan 13, 9:50 pm, Carl Banks <pavlovevide... at gmail.com> wrote:
> >> The cultural impact that would have on the community is far worse,
> >> IMHO, than any short-sighted benefits like being able to catch an
> >> accidental usage of an internal variable. Trust would be replaced by
> >> mistrust, and programming in Python would go from a pleasant experience
> >> to constant antagonism.
>
> > And I'll give you a perfect example:
>
> > XML-DOM versus ElementTree
>
> > XML-DOM is the sort of standard that is borne of a culture that values
> > encapsulation, strict type safety, and so on.  It's the way it is
> > because designers were allowed to distrust the user, and the culture
> > said that it was good to distrust the user.  Consequently, the interface
> > is a pain to use, with all kinds of boilerplate and iterator types and
> > such.
>
> > ElementTree was borne out of an environment where implementors are
> > forced to trust the user.  As a consequence it was free to create an
> > interface that was natural and straightforward and pleasant to use,
> > without having to be guarded.
>
> Which is all well and good, but there are circumstances where you *don't*
> want to trust arbitrary parts of your code to change other parts of your
> code, for good reason. In other words, you don't always want to trust
> your users.
>
> Forget copy protection and DRM. Think about the software controlling a
> radiation machine for cancer treatment, with a limit on the number of
> rads it fires at any one time. It would be disastrous for any arbitrary
> function in the machine's software to be able to mess with that limit,
> accidentally or deliberately. People will die if you get it wrong.

I'm on record saying Python shouldn't be used for systems with the
possibility of catastrophic failure: that's with or without
encapsulation.  Too much happening internally to account for it all.

Frankly I'm not sure that C++ and Java's encapsulation is good enough,
either.  Software-enforced encapsulation can be subverted, and
sometimes invalid access can happen from within the protection zone.
If something's that important, it needs to be running with redundancy
and lots and lots of fault tolerance, and it needs to have the hell
tested out of it.  If it's critically important, the code should be
storing the critical information in a separate data area with a higher
privledge level than the rest of the program.  The simpleminded
encapsulation schemes of C++ and Java are weak compared to these
methods, and probably wouldn't add much.

As I said, I've worked on flight control systems that didn't use any
data hiding at all.  Even if a drastic coding mistake like you
mentioned was able to make it though dozens of peer reviews and
hundreds of tests, it still might not result in catastrophic failure
because of all the fault tolerance built-in.



Carl Banks