Python design philosophy

[Warren Postma]

> I am *brand* new to python (as of Sunday), and I just got to the section
> in the tutorial about classes.  I was wondering why there really isn't
> such an idea as a "private" member of classes?  I understand that members
> can be hidden, but not really protected from the user.  I was wondering
> what the benefit of this would be?  Wouldn't it open the possibility of
> security holes?  Also, what benefit is gained by allowing a user to
> add/delete members from existing classes?  Wouldn't it be more desirable
> to create his/her own derived class?

The simplest way for me to put it is that it makes the Python language
simpler, easier to learn, and more "compact" in terms of remembering how to
program in it.  That freed up space can be used for thinking on higher
planes than I find I normally think on when programming in C. Just as there
is no way to declare a variable as an integer, or a function as returning an
integer, there is no way to make that member variable or member function
private, static, or a constant.  You might mourn that loss, but that shows
that you are transitioning still from thinking like a
statically-typed-language programmer to a dynamically-typed-language
programmer.

Now, sometimes an idiom replaces a keyword.   For example, if you want
something to be apparently private, one idiom is to append underscores to
the name, which in programmer-idiomspeak means "don't mess with this if you
know what's good for you". It could also mean (more open mindedly, mess with
this only if you really know what you're doing). In fact the latter is
actually a better way to build systems in a dynamically typed language like
Python.   Another way to make private members is to mess with __getattr__
and __setattr__.

The adjustment period from C or C++ involves a few "Do you really need X?"
type of  dilemmas. You'll find that there are ways to implement something
like X in Python, but that it is seldom worth bothering to make anything
hidden, in practice.

Warren