[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...
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
