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

[Mike Meyer]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
> Mike Meyer <mwm at mired.org> writes:
>> > Yes, the point is that it's something that you can check for by
>> > examining the class in question without having to examine any other
>> > classes.
>> 
>> That's a pretty restrictive convention to follow.
>
> What convention?  It just makes it possible to write code with some
> specific invariants if there's a need to do so.

That you don't pass private variables to a function unless it's a
buitin. Python is *not* a strict OO language, and uses utility
functions for lots of things. To make private work the way you have to
change the library to use a strict OO approach, probably including
providing a real hierarchy instead of just duck typing.

>> So it turns out that getting the behavior you desire involves
>> following a lot of conventions.
>
> That improves on the current situation.  Right now the behavior is
> impossible to obtain in Python no matter how many conventions you
> follow, unless you follow them through a whole program of arbitrary
> size instead of just in the class that you're trying to protect a
> variable in. 

Just adding private doesn't change this significantly - it just makes
the compiler enforce one of the large number of conventions you have
to follow.

>> In other words, by adding private to python, you're making it so that
>> bugs involving overwriting a private attribute will involve only the
>> owning classes code so long as everyone follows the conventions that
>> exist about the use of such variables.
> Not everyone, just the author of the class that uses the private
> variable.  That's the point.

Except that, with Python as it exists today with a private keyword
added, it's *still* everyone. The only convention breaking the private
keyword would allow the compiler to catch is a reference to
foo.private. It wouldn't catch overriding things in __builtins__ or
overriding builtins in a module, or things poking at the variable
through __dict__, or - well, there are probably lots of things that
need to be dealt with.

>> > I don't see how pylint could know which instances to flag,
>> I was thinking it would flag any use of such a variable where the
>> target variable wasn't "self". That may be a stronger constraint than
>> you wanted - but that's good, right?
> Shrug.  That might be of some limited usefulness, but all it tries to
> do is prevent accidents.  And it does nothing about setattr/getattr.

Preventing accidents is all "private" does - without fundamental
changes to the implementation of the language. You have to catch every
mechanism that can be used to find a reference to an attribute, like
references to __dict__ and to the class variable.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.