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:
>> > 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 builtin.
> No, I don't see that as "convention", it's just something that you do
> if you want to make sure that all the references are local or
> builtins.

Semantics...

> It's like saying that if you if you want to be sure that x
> is always positive, then don't execute statements like "x = -3".  I
> wouldn't call something like that a "convention".

Right - that's not a convention. That behavior would be a convention
if you did somehing like prefixing the variable name with a "p" to
indicate that you don't do that.

> maybe I'd like to be sure that x never yields negative numbers.
> CPython happens to have some features that stop me from guaranteeing
> that invariant.

I'd say CPython was missing the features that you need to guarantee
that. Missing quite a *lot* of features, in fact. But Python has never
been about keeping people from writing bad code - it's about helping
people write good code.

>> 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.
> Yes, but I see all of those as implementation artifacts, not anything
> fundamental.

Right - those aren't fundamental. It's things like Python allowing
programmers to use whatever style is appropriate to the problem at
hand, rather than insisting on an OO style. Once you get outside the
OO style, "private" attributes becomes problematic.

>> 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.
>
> The Python stdlib for a long time had a module called Bastion that
> attempted to do exactly that, so you can't say that the desire is
> un-Pythonic.

Of course I can say it's unpythonic. I might even be right: just
because the standard library does something doesn't mean that
something is automatically pythonic. But I haven't said that "private"
is unpythonic. I will say that the things you need to program
effectively with private variables - like having to inherit all your
utility functions - is unpythonic.

> Bastion was only removed because implementation issues
> kept it from working properly.  Those issues probably can't bbe
> resolved in the 2.x series but as the language evolves, maybe
> something can be done to bring it back.

Pretty much every attempt to restrict what other programmers do in
Python has failed - for "implementation issues". I think that's a good
sign that this kind of thing isn't going to work without some serious
work on the interpreter.

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