Paul Rubin <http://[EMAIL PROTECTED]> writes:
> Mike Meyer <[EMAIL PROTECTED]> writes:
>> Unless your compiler detects and flags passing private variables to
>> external functions all you've got is a convention that you don't pass
>> private variables to external functions.
> 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. For instance, I
might want an error dialog to be a private variable of a class
representing a window - after all, I don't want anyone else writing to
it, or using it in any way. Except, of course, for any GUI framework
routines I have to pass it to in order to use it. This problem crops
up for every utility routine in every library I might want to
use. Opening files by name, concatenatting strings (or are we going to
have a convention that implicit invocation of functions with the
operator syntax don't count, and another one that you don't overload
operators with destructive functions, and so on), etc.
So it turns out that getting the behavior you desire involves
following a lot of conventions.
>> I you going to try and tell me thas using builtin functions on
>> private variables is something you don't allow in your projects?
>
> You have to treat builtin functions as part of the language. Of
> course Python has this situation where someone could rebind the name
> "len" to some other function, so you have to deal with that too, maybe
> just at the file scope.
File scope isn't good enough for python.
import madhouse
madhouse.len = my_len_breaker
fool = madhouse.Fool()
print fool.break()
and fool._foo is broken again.
> An OOP approach (lst.len() instead of len(lst)) that binds the
> builtin names to datatypes might be preferable in some situations
> but I'll leave that one for the theorists.
In other words, to get this to work the way you want, you need yet
another convention - this one being about how one goes about writing
utility functions. It may be that you can design a language and
support libraries so that the compiler can enforce all your
conventions. There are languages that try to do that. I recall one I
ran into in the 70s that distinguished between "functions" (which
returned values) and "procedures" (which had side effects), and the
compiler enforced (or tried to) the distinction. I think you'd need
something like that.
But that isn't what we've got. What we've got is Python. Which means
you need a whole boatload of conventions to make this work the way you
want.
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.
This should be contrasted with the current situation, where bugs that
involve overwriting an _-prefixed attribute will involve only the
owning classes code so long as everyone follows the conventions that
exist about the use of such variables.
Yeah, I guess private makes things a lot better.
>> Of course, there's nothing wrong with catching errors earlier. Might I
>> suggest that you file a change request for pylint (or your favorite
>> error checker) asking that it start issuing warnings for
>> object._variable?
>
> I don't see how pylint could know which instances to flag, without
> doing type inference on all the objects to know that the variable
> belonged to an instance of some other class.
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?
<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
