Mike Meyer wrote: > [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. As has been > indicated, using two variables is ba well-respected method of doing > this. Another alternative (on the spur of the moment - I have no idea > how well this will really work) is a value-carrying "invalid value": > > # untested code: > class Invalid: > state = 'unknown' > > ... > > if self.count is Invalid: > if self.count.state == 'unregistered': > # Register self. > elif self.count.state == 'registered': > # Whatever > else: > # Deal with self.count outstanding requests > > Hmm. I'm not sure I like this... > He doesn't need to test the type, in this case.
if self.count is False: elif self.count is True: else: The alternative suggested : if self.state is False: elif self.state is True: else: deal with self.count I don't see much difference. He can also use a better name to represent True/False. Registered=True UnRegistered=False -- http://mail.python.org/mailman/listinfo/python-list
