Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; '(except': 0.05; 'say,': 0.05; 'false,': 0.07; 'raised': 0.07; 'skip:/ 10': 0.07; 'undefined': 0.07; 'from:addr:ethan': 0.09; 'from:addr:stoneleaf.us': 0.09; 'from:name:ethan furman': 0.09; 'if,': 0.09; 'logger': 0.09; 'message-id:@stoneleaf.us': 0.09; 'received:184.172': 0.09; 'received:gator410.hostgator.com': 0.09; 'subject:while': 0.09; 'sure,': 0.09; 'terms,': 0.09; '~ethan~': 0.09; 'stored': 0.10; 'thread': 0.11; 'bug,': 0.16; 'distinction': 0.16; 'nameerror': 0.16; 'wrote:': 0.17; 'examples': 0.18; '(or': 0.18; 'appropriate': 0.20; 'either.': 0.22; "haven't": 0.23; 'testing': 0.24; 'header:In-Reply-To:1': 0.25; 'header:User- Agent:1': 0.26; 'andrew': 0.27; "doesn't": 0.28; 'record': 0.28; 'index,': 0.29; 'spaces': 0.29; 'table,': 0.29; 'maybe': 0.29; 'function': 0.30; 'code': 0.31; 'point': 0.31; 'could': 0.32; 'to:addr:python-list': 0.33; 'false': 0.35; 'something': 0.35; 'but': 0.36; 'anything': 0.36; 'should': 0.36; 'being': 0.37; 'why': 0.37; 'data': 0.37; 'subject:: ': 0.38; 'object': 0.38; 'some': 0.38; 'nothing': 0.38; 'instead': 0.39; 'to:addr:python.org': 0.39; 'list,': 0.39; 'header:Received:5': 0.40; 'think': 0.40; 'red': 0.60; 'real': 0.61; 'truly': 0.62; 'more': 0.63; 'date,': 0.65; 'records': 0.68; 'eight': 0.71; 'received:64.5': 0.84 Date: Tue, 17 Jul 2012 05:35:52 -0700 From: Ethan Furman User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "comp.lang.python" Subject: Re: Implicit conversion to boolean in if and while statements References: <5002a1f9$0$29995$c3e8da3$5496439d@news.astraweb.com> <50037eab$0$29995$c3e8da3$5496439d@news.astraweb.com> <50047A84.6020208@gmail.com> <5004b543$0$29978$c3e8da3$5496439d@news.astraweb.com> <5004ec84$0$11116$c3e8da3@news.astraweb.com> <5004F5F4.5000601@gmail.com> In-Reply-To: <5004F5F4.5000601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator410.hostgator.com X-AntiAbuse: Original Domain - python.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - stoneleaf.us X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.74.2]) [50.137.155.36]:1526 X-Source-Auth: ethan+stoneleaf.us X-Email-Count: 2 X-Source-Cap: dG9idWs7dG9idWs7Z2F0b3I0MTAuaG9zdGdhdG9yLmNvbQ== X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 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: 44 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1342528875 news.xs4all.nl 6928 [2001:888:2000:d::a6]:60963 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:25493 Andrew Berg wrote: > To put it in duck-typing terms, why should everything have to quack like > True or False? Sure, I can see why 1 quacks like True or [] quacks like > False, but I don't see why say, a Logger or function should quack like > either. Should a Thread object be True if it's been started and False > otherwise? True and False are red herrings. It is more appropriate to think that True quacks like something and False like nothing than the other way 'round. Maybe some examples from my own code will help: DbfTable --> True if any records in table, False otherwise DbfIndex --> True if any records in index, False otherwise DbfList --> True if any records in list, False otherwise DbfDate --> True if a date, False otherwise (could be eight spaces instead of a real date) DbfDateTime --> True if a datetime, False otherwise DbfRecord --> True always DbfRecordTemplate --> True always DbfRecordVaporware --> False always While I could have DbfRecord be False if, for example, it had no data stored in it, I have no use case for that scenario so haven't bothered. Also, at this point I am using the distinction of True/False with regards to records to determine if I have a real record (True means a record/template I can read/write, False means I don't). > If it truly is about something vs. nothing, why is a NameError (or > AttributeError) raised when testing with an undefined variable? Being > undefined quacks like nothing, doesn't it? It's about /representing/ something vs. nothing. An undefined name isn't representing anything (except a bug, of course ;). ~Ethan~