Antoon Pardon wrote: > Op 2005-12-14, Grant Edwards schreef <[EMAIL PROTECTED]>: > > On 2005-12-14, Antoon Pardon <[EMAIL PROTECTED]> wrote: > > > >>>>> Well, as you might argue, I'm not tryng to effect a change in > >>>>> your behaviour, I'm simply trying to point out how it could be > >>>>> made more rational. > > [...] > >>>> 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? 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 > > ... > > 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? That is what I would do in C or similar language where a variable can only be one type.
-- http://mail.python.org/mailman/listinfo/python-list
