Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!nzpost1.xs4all.net!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'binary': 0.05; 'one?': 0.05; 'imply': 0.07; 'directions': 0.09; 'least)': 0.09; 'received:internal': 0.09; 'sane': 0.09; 'thu,': 0.15; "'in',": 0.16; 'comparisons,': 0.16; 'message- id:@webmail.messagingengine.com': 0.16; 'operators.': 0.16; 'readability.': 0.16; 'received:10.202': 0.16; 'received:10.202.2': 0.16; 'received:10.202.2.44': 0.16; 'received:66.111': 0.16; 'received:66.111.4': 0.16; 'received:66.111.4.27': 0.16; 'received:compute4.internal': 0.16; 'received:messagingengine.com': 0.16; 'received:out3-smtp.messagingengine.com': 0.16; 'wrote:': 0.16; 'language': 0.19; 'not,': 0.22; 'saying': 0.22; 'arguments': 0.22; 'either.': 0.22; 'explicit': 0.22; 'sep': 0.22; 'trying': 0.22; '(where': 0.23; 'this:': 0.23; 'header:In-Reply-To:1': 0.24; '(e.g.': 0.27; 'values': 0.28; 'arithmetic': 0.29; 'comparison': 0.29; 'equally': 0.29; 'operators': 0.29; 'other,': 0.29; "i'm": 0.30; 'certainly': 0.30; 'operations': 0.31; 'included': 0.32; 'statement': 0.32; 'class': 0.33; 'problem': 0.33; 'combination': 0.33; 'operations.': 0.33; 'definition': 0.34; 'except': 0.34; 'ones': 0.35; 'expected': 0.35; 'but': 0.36; 'should': 0.36; '(3)': 0.36; 'cases': 0.36; 'to:addr:python-list': 0.36; 'subject:: ': 0.37; 'received:10': 0.37; 'two': 0.37; 'being': 0.37; 'say': 0.37; '(2)': 0.37; 'received:66': 0.38; '(1)': 0.38; 'mean': 0.38; 'means': 0.39; 'why': 0.39; 'does': 0.39; 'to:addr:python.org': 0.40; 'your': 0.60; 'header:Message-Id:1': 0.61; 'more': 0.63; 'home': 0.67; '*really*': 0.84; 'now)': 0.84; 'subject:True': 0.93 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=YNwvwwD4yQFdqHfTCTdexGecjv0=; b=AfWmWS XyHVRdiklkojn72Hr45RQ88iyASnR2PLPXFPN9rS4gq9t602hqCgr0VxuAbNqfCU TbXJHcIq4D2WGx66u1rnw+8YzXkRwSM0fFCkYhXcN6hqHdFTx/DWQEs7cOOqSkRM 8mHkY97bcprklpAbudNMrzwZuldlYontIH+o8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=YNwvwwD4yQFdqHf TCTdexGecjv0=; b=L3xfUS+uHVijbDLAiDYvX0CJxRyp/Th22QZzr9vJiKxkyF8 y0EZkvMyhFvEp70kTHgNtr21Rlq3JQaDLpzkBfodYM1WVqu/hbqD6+ZQ849vXpqU GZ3QYbhn7HLwYn02FeSwhRO2kunfpdbOR4cNl18jtGa/0Ffxmq5eqNHBRs9Y= X-Sasl-Enc: dv35zZU7Dlu2B02aC7+Uc8FgvQQ01vSnhpwSkOai0bWm 1442525214 From: Random832 To: python-list@python.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-746d2121 Subject: Re: True == 1 weirdness Date: Thu, 17 Sep 2015 17:26:54 -0400 In-Reply-To: References: <0b949fe0-09b4-46b0-b4ac-a85a9bfebfd5@googlegroups.com> <1442412230.1762717.385286049.20841F36@webmail.messagingengine.com> X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.20+ Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 37 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1442525221 news.xs4all.nl 23821 [2001:888:2000:d::a6]:34258 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:96784 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. > 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. 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 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. 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). 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.