Will python never intend to support private, protected and public?

[could ildg]

**Encapsulation** is one of the 3 basic characteristics of OOP.
When I firstly turned to python, it was my first script language.
That time I found that python has not real private properties,
I felt weird. If an oop language can't encapsulate something I want,
is it really an oop language? I asked myself. And after thinking for
some days, I answered myself that python is just a script language,
it has no private stuff just want to keep python easy. An easy language
is hard to do difficult works, surely.

But when I came to know *Ruby* some days ago, I found that not all
script languages have no private functionalities. Ruby has everything
that encapsulation should has. In ruby there is a very popular web
framework named Ruby On Rails. Many programmers are study
at rails these days, And some people think that rails is even better
than J2EE. So I asked myself, why is rails written in Ruby but not
Python since python is such a good language? Why did the author
choose ruby other than python?

On the comparison between py and ruby, the encapsulation of Ruby
**beats** Python.

Why does oop languages need encapsulation?
Because it make programming easier.

Now I give some examples where real private is very very needed.

The counter of a list-like object is very comman in our programms.
This kind of variables can only be modified by the functions of the
class itself. We can't let others has the opportunity to modify it.
If it's modified outside the class directly, the programm will become
very diffict to maintain and understand. At this time, python is not better
than C.

Sometimes I don't want a variable to be changed directly,
It can only be changed through a method. Because I want to
do some extra works when it's changed. e.g:
___________________________________________
class a:
i=0
def setI(iii):
if self.i!=iii:
self.i=iii
#do some extra works here, e.g, notify the observers that
#this property is changed, or do some logging things.
___________________________________________
In the class "a" above, when "i" is changed, I will do some extra works,
the extra works could be very import, so I want to keep i invisible
to some others, they can only change i by the method setI. But python
can't ensure i to be invisible, everyone can change it whenever they
want! This is dangerous.

Some guys will say that they will pay very much attention when they
change the variable i. But, I just want to say that this is only the easiest
situation because there is only **one** class and only **one** variable
which should be visited cautiously. But what will you do when there are
hundreds of classes and each class has dozens of such variables? I think
everybody can imagine how difficult it will be when he faces this
situation.

Every programmer is just a human being, but not God. Our life is limited,
our time is limited, so we need to use convenient tools to save time.
Private variables guarantee that we will never make stupid mistakes
to change them incautiously and it will tell us that "YOU ARE WRONG" when
you try to change or visit them. They save energy for us, they save time
for us, they make us to be God!

I don't want to give any more examples where private variables should be
used. If you think it's not needed, that's not import for me. I just want to
say
that encapsulation is very very needed, just as one's cock, it's his, and
it's
only his. He can't unconditionally let anyboy else tough it. Because it's
dangerous. So he should hide it, but not to expose it and tell everybody
else
verytime "Don't tough my cock, it's my private stuff!".

I use python for more than a year and I can't leave it because I am familiar
with my everyday necessary libs. And it's so convenient to interact with
python from Delphi or C or C++. I like pyton, so I like python to be
perfect,
I wish everyone of us could have a perfect python, so it is with you, isn't
it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20050929/62458854/attachment.html>