Op 2005-12-14, Mike Meyer schreef <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] writes: >> Steve Holden wrote: >>> >>It would be somewhat more self-documenting, but why not just use one >>> >>name to indicate the state and another, only meaningful in certain >>> >>states, to indicate the callback? >>> > Why should I do that? Checking the type of a variable is conceptually >>> > no different form testing set membership. So what I did, was just >>> > bringing two disjoint sets togther and working with a variable from >>> > that union. This is all in all a rather simple mathematical idea. >>> > And I don't see why I should put certain information into a seperate >>> > variable. It makes as much sense as working with numbers and using >>> > a seperate variable to store whether a particular number is postive, >>> > even or has some other characteristic. You don't seperate information >>> > you can easily acquire from the variable itself. So why should I >>> > seperate this information that is aquired just as easily? >>> 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. >> What would be the difference in his usage and allowing Null in a RDBMS >> column ? Or return NaN instead of raising exception for numeric >> functions ? > > Having a value to indicate "no value" is, of course, perfectly > reasonable. However, you then test *for that value*; you don't test > the type of the value to see if it's of the right type. > > Once you get beyond the variable either having a valid value or not, > it's really time to consider a different approach.
How do you feel about testing for set membership? I can have a set with values to be treated differently than values not in the set. Do you consider that an acceptable approach? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
