Steven D'Aprano wrote: > I look at it this way: as the class designer, I have ZERO idea what > attributes and methods of my class will be just the perfect thing to solve > somebody's problem, so it is rude of me to lock them up as private -- > especially since they *will* find a way to hack my class and access my > private attributes and methods anyway.
Actually, one good aspect of "attribute privacy" is the lowered risk of instance attribute name clashes. When subclassing from some partly abstract class in order to specialise its behaviour (sgmllib.SGMLParser, for example), one has to make sure that one doesn't reuse some instance attribute name by accident - doing so could potentially cause behavioural issues in the superclass's mechanisms. That said, Python does at least let you look at which attributes are already defined in an instance due to the lack of privacy, so it does offer some kind of solution to that problem. Moreover, Python also lets you define double-underscore attribute names which behave give instance attributes privacy in all respects, being invisible to users of the instances concerned, accessible only within methods belonging to the defining class, and safely overloadable in subclasses without incurring conflicts. Generally, I'm in agreement with you, though: private, protected and final are all things which provide easy distractions from more serious and demanding issues. They can quite often prove to be "the bikeshed" in system design and implementation. Paul -- http://mail.python.org/mailman/listinfo/python-list
