Wow, I got a lot more feedback than I expected! I can see both sides of the argument, both on technical merits, and more philosophical merits. When I first learned C++ I felt setters/getters were a waste of my time and extra code. When I moved to C# I still felt that, and with their 'Property" syntax I perhaps felt it more. What changed my mind is when I started placing logic in them to check for values and throw expections or (hopefully) correct the data. That's probably reason one why I find it weird in Python
Reason two is, as the user of a class or API I *don't care* what is going on inside. All I want visible is the data that I can change. The '_' convention is nice.. I do see that. I guess my old OOP classes are hard to forget about. I feel that the state of an object should be "stable" and "valid" at all times, and if its going into an unstable state - error then, not later. That's why I like being able to protect parts of an instances state. If, as a provider of a calculation engine, I let the user change the internal state of the engine, I have no assurances that my product (the engine) is doing its job... <shrugs> I appreciate all the feed back and enjoyed reading the discussion. It helps me understand why Python community has chosen the road they have. - Thanks. -- http://mail.python.org/mailman/listinfo/python-list
