Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
