John Yeung wrote: > Paul LaFollette is probably thinking along the lines of formal logic > or set theory. It's a little bit confused because programming isn't > quite the same as math, and so it's a common question when designing > and implementing programming languages how far to take certain > abstractions. In some languages, nil, null, or none will try to > behave as mathematically close to "nothing" (complete absence of > anything) as possible, even though in reality they have to have some > concrete implementation, such as perhaps being a singleton object. > But mathematically speaking, it's intuitive that "nothing" would match > any type.
I think you're wrong. Mathematically, you can't mix types like real numbers and sets: while 1+0 = 1, you can't expect to get a sensible result from 1+{} or {1}∩0. (If that character between the set and zero ends up missing, it's meant to be INTERSECTION u'\u2229'.) Similarly, you can't add a scalar to a vector or matrix, even if one or the other is null. > I find that it's somewhat like the confusion that often occurs > regarding the all() function. Some people are surprised that all([]) > returns True, but it's the same logic behind the truth of the > statement "every element of the empty set is an integer". It's also > true that every element of the empty set is a float. Or an elephant. So-called "vacuous truth". It's often useful to have all([]) return true, but it's not *always* useful -- there are reasonable cases where the opposite behaviour would be useful: if all(the evidence points to the Defendant's guilt) then: the Defendant is guilty execute(the Defendant) sadly means that if there is no evidence that a crime has been committed, the person accused of committing the imaginary crime will be executed. -- Steven -- http://mail.python.org/mailman/listinfo/python-list