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

[Paul Rubin]

Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
> 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.

I don't see that as part of the philosophy of dynamic languages.  For
example, the Python language spec describes a way to reach the private
variables of class instances (through name mangling) but not a way to
get at the private variables of closures or generators (though you can
still do that in CPython through some implementation-specific hacks).

I don't think those implementation hacks are a deep philosophical
consequence of anything, and Python would still be Python without
them.  I don't see why generator designers should be any different
from class designers in your logic.  Why is it so important for
freedom-loving programmers to be able to mess with the private
variables of instances but not of generators?  How are they different?
(Answer: They are not different.  Both are unimportant.)

> 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 do you think the designer and user are necessarily not the same
person?  Maybe an app writer wants to create some fault tolerance by
implementing privilege separation inside an application.  I mentioned
in another post that I wrote a crypto class that does exactly that, by
putting the crypto variables in a separate Python interpreter from the
client, and communicating by RPC over sockets.  I'm both the designer
and the user, and I wanted to protect the data in some of the classes
I wrote from code from possible misbehavior of other classes that I
wrote.  With private variables, I could do that in a single process
with reasonable security and much less overhead.

> Why should the class designer get a monopoly on deciding what the
> class user can or cannot do?

Um, because the designer wrote the code?  If the designer chose an
algorithm that's not to the user's liking, the user's only way to fix
it is by modifying the code (and thereby becoming a co-designer).
What's special about instance variables, that they should all be
accessible from elsewhere in the program without modifying the code?

> If you believe that the class designer should have the privilege of
> prohibiting certain uses of the class,

Not the class, just instances of the class in a running program.  The
user can always repurpose the class by modifying the code and making
new instances of the modified class.

> you will vote for private variables. If you believe that the class
> users should have more freedom, you will vote against them.

You're assuming some kind of conflict between the designer and the
user.  If the app is such that a conflict actually exists (e.g. the
user is a possibly-hostile applet), then letting the designer enforce
security is essential.  If no conflict exists, then the designer and
user (who might be the same person) can work out something to their
satisfaction.

> "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.

The right way to extend or override class method behavior is by
subclassing or changing the implementation.  This notion of reaching
into the private variables of running instances is a violation of type
safety and a silly hack.