On Sat, 16 Dec 2006 05:24:28 -0800, [EMAIL PROTECTED] wrote: >> > Hi, In the following program, I have a class Test which has a property >> > x. Its setx function gets a string value and converts it into a float >> > and stores into it. >> >> [snip code] >> >> Python isn't Java. Are you sure you need properties? > > I do not know Java. But, object.x = value looks much better than > object.set_x(value) . Is there any harm in doing it, provided I have to > do more than just storing the value.
Why write set_x in the first place if all it does is set x? Why not just have an attribute x and just write obj.x = value? What advantage are you gaining? One good use of properties is when you need attribute x to be calculated on the fly. But there are costs as well: accessing a property is more expensive than just accessing an attribute (accessing a property means that not only do you access an attribute, but you also run a method). That might not matter if your getter and setter are simple enough. Another cost is that you have to write the code in the first place, and then you have to test it: your class becomes bigger and more complicated. One reason why getters and setters are looked at suspiciously is that in the Java world, they frequently lead to bloated code. If you gain no benefit from that complexity, why pay for it? I'm not telling you "don't use properties" -- I'm merely telling you to think about why you are using getters and setters in the first place, and be sure that you are gaining benefit from them. I'm suspicious about your example, because your getter simply looks up a private attribute and returns it. Your setter does barely more work: it calls float. I'm guessing that your intention is to try to ensure that obj.x is only ever a float. But Python isn't designed for that sort of strong type checking. It is very, very hard (possibly impossible) to ensure calling code can't abuse your classes, and type-checking languages only protect against one small set of potential abuse anyway. The usual Python philosophy is not to bother, and instead rely on good unit testing to test for all bugs, not just type bugs. Your class as a tool. All tools can be used or misused. It isn't the responsibility of the tool to protect you from misusing the tool (because it can't, even if you wanted it to -- the best it can do is protect you from some misuses). It is the responsibility of whoever uses the tool to not misuse it. In practice, what that often (but not always) means is that if you have an attribute x that needs to be a float, your class is entitled to assume it will always be a float, and the code that uses your class is responsible for making sure that it never stuffs a non-float into x. If it does, that's a bug in the caller, not in your class, and is best caught by unit testing. (But does x really need to be a float? Maybe it only needs to be an object that acts like a float.) That's just something for you to think about. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
