Antoine De Groote <[EMAIL PROTECTED]> writes: > To me this seems contradictory. Why would one not want to do something > that is included in the documentation? Or am I just confused? Does > anybody have an idea how to put me in the right direction?
The library reference states the technical procedures for doing various things. That is, it explains how the procedures work. It doesn't say when to use one procedure or another. It's a technical reference, not a style guide. > And then, by (2) I believe that what is meant is that once some client > code uses public fields one can't make them private anymore because > then the clients are broke. That's clear to me. But I don't understand > (3). I don't know exactly what they mean. How would one want to change > their mind? In what way? I've been thinking about it some time now, > but I'm still kept in the dark. I would appreciate any explanation. I think it means the example you cited from the library doc is inadvisable in practice, and should only be used as a template for more complicated getters and setters. E.g. if you want the client to be able to set foo.x to an arbitrary value, don't use a setter, just say foo.x = 237 and the attribute value gets set directly. If you want to limit the value of foo.x to the range 0-100, and make setting to outside the range clip to that range or raise an exception or something, THEN use a setter. In Python, you can omit the setter at first (so there's no restriction), then later decide you want to add the restriction, so you add the setter. In Java, if you omit the setter at first and then later want to add it, you have to change all the client calls. -- http://mail.python.org/mailman/listinfo/python-list