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

[Steven D'Aprano]

On Fri, 30 Sep 2005 03:42:32 -0700, Paul Rubin wrote:

> Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
>> Still, en.karpachov at ospaz.ru's point that you must know the base classes
>> is correct. It is *easy* to find them out (NotSoSecret.__bases__ should do
>> it), but if you don't you are taking a chance that your class name doesn't
>> clash with one of the bases.
> 
> It's not easy if the base classes change after you check your code in.
> You shouldn't need to know about that if it happens.  Modularity, remember?

Yes. And if you are relying on a public method in a class, and somebody
dynamically modifies that public method, your code will stop working too.

py> class Klass:
...     def spam(self):
...         return "spam"
...
py> def food():
...     c = Klass()
...     return c.spam()
...
py> food()
'spam'
py> Klass.Spam = Klass.spam; del Klass.spam
py> food()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 3, in food
AttributeError: Klass instance has no attribute 'spam'



Let's be frank. When you have a dynamic language like Python, the cost is
that somebody -- even yourself -- can pull the rug out from under your
feet. But that cost gives you flexibility and power. While your
competitors are still defining the variables and their types in some other
language, you've finished and debugged your entire program. 

Now maybe they can put their hand on their heart and say with absolute
100% mathematical certainty that there are no bugs in their code, and you
can't do that, and perhaps that mathematical certainty is appropriate for
your ICBM control system or nuclear reactor, but it is a needless
affectation for (say) a word processor. 


-- 
Steven.