"Russ P." <russ.paie...@gmail.com> writes: > Actually, in addition to the enforcement of "private," you also need > the enforcement of "protected."
Oh, heavens. If you want C++ or any of its progeny, you know where to find them. Besides, those languages have a horrific design mistake because they conflate the class system (which manages the units of behaviour) with the module system (which deals with the units of implementation). It's precisely because Python's boundaries are fairly porous that it doesn't fall into this trap. (There's the small matter of sharing the class and instance attribute namespaces, but a little bit of care seems to work out OK.) Even so, why do you think you are that you know better than the next programmer -- whoever he might be -- which parts of your class he should mess with? You can make suggestions, recommendations, in your documentation: provide the raw materials so that he can make informed decisions about whether he wants to mess with your class's internals. But the `here's a black box: there isn't and never will be any justifiable reason why you might want to poke about inside' control-freakery of people who like this sort of thing just rubs me up the wrong way. Yes, I know that some people have to work with drooling idiots who don't know a stable interface from volatile implementation details or documented behaviour from a bug that'll be fixed in the next version. Python just isn't the right language for those people. They can use Java or something -- hey, it's presumably good for something, maybe it's this -- but those who know better don't deserve to be penalized for their sake. -- [mdw] -- http://mail.python.org/mailman/listinfo/python-list
