On 2005-12-15, Antoon Pardon <[EMAIL PROTECTED]> wrote: >>>>> Or return NaN instead of raising exception for numeric >>>>> functions ? >>>> >>>> Because usually (in my applications anyway) NaN is a perfectly >>>> valid value and not an "exception" case that needs to be >>>> handled. >>> >>> I don't see the difference. In my application False and True >>> (or Registered and UnRegistered if you prefer) are perfectly >>> valid values too. They are not "exception" cases that need to >>> be handled. >> >> Well, in my case, a given name (or return value) is always >> bound to a floating point object. I don't test the type of the >> object and treat it in two different ways depending on what >> type it is. It's just a float. > > Do you find that difference so important?
Possibly. In my case, a float is always a float. You can always do the same set of operations on it. > As far as I understand > the gtk identifiers are always positive integers. So I could > have coded as follows: > > UnConnected = (-1, -2) > Registered, UnRegistered = UnConnected In your case, there isn't a single set of operations that work regardles of the value. You have to _check_ the value in order to decide what operations are allowed on that value. I'm not saying the latter is "evil" but I think the distinction is important. > ... > > if self.cb_src in UnConnected: > > Now all values are integers and I no longer treat an object different > depending on type but on value. However conceptually nothing changed. > My code branches depending on set membership of this attribute. > > Could you explain why it should make a (big) difference between > these two approaches? Your examples are still both very different from the NaN example. A NaN is a floating point operation that supports all the same operations as all other floating point operations. In your example an integer object of -2 does not support the same "operations" that a "real" GTK identifier does. They are two different types. -- Grant Edwards grante Yow! Hey, wait a at minute!! I want a visi.com divorce!!... you're not Clint Eastwood!! -- http://mail.python.org/mailman/listinfo/python-list