Mike Meyer wrote: > And you've once again missed the point. The reason you don't > manipulate the attributes directly is because it violates > encapsulation, and tightens the coupling between your class and the > classes it uses. It means you see the implementation details of the > classes you are using, meaning that if that changes, your class has to > be changed to match. > One of Python's greatnesses is that a property is, for all means an purposes, a fully virtual instance attribute/member.
If you follow the KISS principle, as long as your (naive? probably) implementation of the class has "real" attributes and their manipulation is meaningful & makes sense from an external point of view, just leave it at that. If you happen to change the implementation for whatever reason and happen to remove the real attributes, just create virtual attributes with a property and be done with it. Wrapping everything just because you can and considering that encapsulation is only truly done if you never happen to touch what's under the hood (even without knowing it) is the Java Way, this is Python. In Python, the interface of an object instance is always virtualized because you can never know if you're manipulating "real" attributes or property-spawned virtual attributes. _that_, in my opinion, is not knowing about the implementation details. While a Java object is mineral (set in stone) and trying to abstract everything from the start (and generate 50 pages documentation for each class to be sure that you didn't miss anything) kind of makes sense, a Python object is an organic, morphing, living entity. Don't abstract everything and over-engineer from the start just because you can and because you'd do it in Java or C#, only abstract (from your point of view) when you *have to*. And remember that "Java's Object Oriented Programming" is not the only one worth using, even though some people would like to make you believe it. -- http://mail.python.org/mailman/listinfo/python-list
