catching exceptions

[Steven D'Aprano]

On Sat, 16 Dec 2006 05:24:28 -0800, jm.suresh at no.spam.gmail.com 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.