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

Steven D'Aprano steve at REMOVETHIScyber.com.au
Mon Oct 3 01:06:37 CEST 2005

On Sun, 02 Oct 2005 12:05:53 -0700, Paul Rubin wrote:

> I just don't understand your point here.  Yes, you can do all those
> things and leak any variable.  However, if you want to NOT leak some
> particular variable, "private" lets you code in a way that lets you
> easily confirm that you didn't leak it.

I think folks are missing an important point here.

The philosophy of dynamic languages like Python is that the class designer
shouldn't be the only one who decides whether or not a particular variable
should be private or public. The designer can *suggest*, but not force.
The class user is free to ignore that suggestion.

The class designer is assumed to know their class best, and therefore be
in a position to know what variables are dangerous or inconvenient to leak
and which are not. But the class user is the person who knows their own
needs best, and therefore best to know whether their needs are such that
they are willing to take that risk. Why should the class designer get a
monopoly on deciding what the class user can or cannot do?

If you believe that the class designer should have the privilege of
prohibiting certain uses of the class, you will vote for private
variables. If you believe that the class users should have more freedom,
you will vote against them.

"Truly" private variables have an advantage of making the class designer's
life somewhat easier -- not much, but a little. But that advantage comes
at the cost of making the class user's life somewhat harder -- not much,
but a little -- by restricting what they can do. Your private variable may
be just what they need to solve some problem you never even thought of.

Python cannot be all things to all people, although it can be many things.
There are always trade-offs to be made. Java makes the trade-off one way,
Python the other.


More information about the Python-list mailing list