Random832 writes: > On Thu, Sep 17, 2015, at 16:24, Jussi Piitulainen wrote: >> And I'm saying 'in', being truth-valued, is more like a comparison >> than a proper binary operation that has its value in the same set as >> its two arguments. > > The problem is that except for very specialized cases (strings), the > two arguments are not (semantically, at least) in the same set as each > other, either. It may be "more" like a comparison, but it's not > *really* like either one.
Agreed. (In hierarchical set theories like ZFC, the membership predicate is between things of the same type, too: sets, the only things there are. That's hardly relevant in a typed setting.) >> Just trying to explain what I had in mind when I said that I feel >> that 'in' is more at home with comparisons (where it is now) than >> with, hm, arithmetic operations. > > Why does it have to be either one? I don't even think chaining should > work for all *actual* comparison operations. To keep the rules simple. To keep the language comprehensible, and then I can take the responsibility to keep my code comprehensible. > Say you have this statement: > (1) a < b = c <= d > While it may *actually* mean this: > (2) a < b and b = c and c <= d > It *semantically* means this: > (3) a < b and a < c and a < d and b = c and b <= d and c <= d I prefer (1) with no hesitation. I start to worry about typos and thinkos when the expression gets longer, and transitivity is such a fundamental notion that I'd rather blame myself for not understanding transitivity than the code for being too concise. (Also, == :) Would really hate to be forced to spell it all out if there were more complicated expressions in the chain. > The ones that are included logically imply the ones that are not, for > any sane definition of these operators. And if your operators *aren't* > sane, it's better to be explicit about what you are doing. Yes. Those, in (1), are sane. > It should not be applied to any combination of operations that cannot > meaningfully be read as such a statement (e.g. mixing directions of > less/greater comparisons, or including in, is not, or != at all), or > to any values expected to have (2) not imply (3). I think (x != w != y) is ok to check that neither of x and y equals w. Even (x < w > y) seems surprisingly clear to me: it's comparing the extreme values to the middle value but not to each other. When in doubt, I might add a comment next to the expression. So in principle I agree. I just seem to tolerate more uses of chained comparisons than you. But longer chains are even rarer than 2-chains, and even 2-chains do not happen so often, and when they do happen, they tend to be (j < k < n). Shrug. > It being *easier to implement* to have comparison operators be a single > class and have chaining apply equally to all of them may be an excuse > for the language to allow it, but it's certainly not an excuse for > *actually* using it from a standpoint of good style and readability. It's also easier to document and comprehend, and on the whole they are a natural class. If something does go wrong, it's nice to find out that the explanation is simple, and not yet another special case that I was supposed to keep in mind. -- https://mail.python.org/mailman/listinfo/python-list
