On Feb 8, 8:23 am, Carl Banks <[EMAIL PROTECTED]> wrote: > On Feb 7, 8:44 am, Steve Holden <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] wrote: > > > I'd like to know what others think about it, about this anti-feature. > > > What I can say is that other computer languages too think that boolean > > > operations must return boolean values only, so I am not alone in my > > > folly :-) > > > Other languages do indeed refuse the temptation to short-circuit, > > Short-circuiting isn't the issue here; a language can short circuit > and still return a boolean. > > > but > > that doesn't mean that Python is wrong to do so. It's a design choice, > > and while you are free to disagree with it I imagine you would be > > pissing in the wind in attempting to get a change like that into Python 3. > > > Most people like the semantics of "and" and "or" as they are. > > I guess I'll agree with bearophile here; I think booleans should be > completely disjoint from all other types, as they are in Java. "and", > "or", and "not" should accept only boolean operands and return only > boolean results. > > I don't deny that it's convenient to use "or" that returns the first > true value, or that it's sometimes a marginal improvement in clarity. > > I just think this idiom is too error prone, and very often too > misleading, to justify its convenience. There's ordinary > carelessness, of course, where someone writes a function like this: > > def op(datum=None): > result = datum or default > > while not stopping to consider that the empty string would be a legal > value for datum in this case. But there's a more insidious danger > that can't be chalked up to carelessness: when the acceptable values > for datum change *after* the function is written. This leads to > subtle breakage. > > As far as the user is concerned, this function's correct behavior is > to "use the default when the argument is not specified", but as-is the > function is not robust to future changes or uses. The function is a > poor, non-robust implementation of the desired behavior. > > To me this feels like a ticking bomb, a bug waiting to emerge from > it's egg. > > More generally: I find that the boundary between what Python considers > to be true and false rarely corresponds exactly to what I'm trying to > do in cases like the above. > Usually the true/false test only works for certain set of expected > values that I have in my mind. When the acceptable values are > generalized, when you want to expand this function's role, does the > true/false test still work? I find it rarely does. > > The Python treatment of booleans is, by far, my biggest gripe with > Python. (Which, you know, is a pretty good thing to have as a biggest > gripe.) > > Carl Banks
Can't you just make a subclass of Boolean and add methods to the true/ false, or am i running up a tree with a cat? I think a clear problem with this is that, this is one area of grief for some users with the Try/Except: clause usage, there are many other examples of this where people would prefer one liners, and a good argument not to allow one is because then you probably wouldn't have a good defence against disallowing the other forms... just-my-one-cent-ly's yours Coko -- http://mail.python.org/mailman/listinfo/python-list