On Tue, 2005-12-13 at 07:26 -0500, Jim Fulton wrote: > I'd add somewhere: "If in doubt, chose non-public. You can always change your > mind later."
Added. > > > We don't use the term "private" here, since no attribute is really > > private in Python (without a generally unnecessary amount of work). > > However, another category of attribute are those which, while not > > being > > public, are intended for use by subclasses (often called "protected" > > in > > other languages). Some classes are designed to be inherited from, > > either to extend or modify aspects of the class's behavior. When > > designing such a class, take care to make explicit decisions about > > which > > attributes are public, which are non-public but useful for > > subclasses, and > > which are truly only to be used by your base class. > > A useful term might be "subclass API". Decide which non-public attributes > are part of the subclass API. Excellent suggestion, thanks. I like the term "subclass API". Added. > > - For simple public data attributes, it is fine to expose just the > > attribute name, without complicated accessor/mutator methods. Keep > > in > > mind that Python provides an easy path to future enhancement, should > > you find that a simple data attribute needs to grow functional > > behavior. In that case, use properties to hide functional > > implementation behind simple data attribute access syntax. > > > > Note 1: Properties only work on new-style classes. > > > > Note 2: Try to keep the functional behavior side-effect free, > > although > > side-effects such as caching are generally fine. > > Personally, I'd actively discourage use of trivial accessors. Simple > attribute access is not only "fine", IMO, but it is much better than > trivial accessors. This is an important point, IMO, because, in my > experience, the vast majority of accessors *are* trivial. I've changed "fine" to "best". -Barry
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
