> Your Python version - from what I can see - works different. > > Art
OK, fun. My Python version goes more like this: Consider if client Z, inhabitant of knowledge domain X, would tend to think of this object-related foo as a noun or a verb, e.g. without knowing anything about Python or programming, but knowing a lot about heart surgery and its objects, is this something I'd like to send arguments to, or will I just set it or consult it, with no sense that I need to tweak parameters? If verb, define a method, and capture the key arguments in a clear API. If noun, then aim to implement as an attribute from the point of view of the user, but if necessary use methods under the hood, as the knowledge domain's concept of noun versus verb may not precisely match your class designs in Python (cite our Triangle example). Bottom line re properties: Python aims to be accommodating and supply a noun where the object's user is already thinking noun (because of the native knowledge domain). With only a few changes, we could make the client *another programmer* i.e. someone fluent in coding idioms. I want other programmers to appreciate my noun-sense and verb-sense, and so I use properties (or not) to communicate these subtle nuances. No one said Python couldn't be subtle. On the contrary, we call it expressive. Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig