Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!xlned.com!feeder7.xlned.com!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.033 X-Spam-Evidence: '*H*': 0.93; '*S*': 0.00; 'else:': 0.03; 'exception': 0.03; 'cases': 0.15; 'ellipsis': 0.16; 'eternal': 0.16; 'forgiveness': 0.16; 'operation.': 0.16; 'passed.': 0.16; 'succeeds,': 0.16; 'wrote:': 0.17; 'numerical': 0.17; 'feb': 0.19; 'sort': 0.21; 'all,': 0.21; 'trying': 0.21; 'import': 0.21; 'earlier': 0.21; 'int,': 0.22; '>': 0.23; 'seems': 0.23; 'raise': 0.24; 'idea': 0.24; 'second': 0.24; 'header:In-Reply- To:1': 0.25; 'supported': 0.26; 'message-id:@mail.gmail.com': 0.27; 'actual': 0.28; 'about.': 0.29; 'attempting': 0.29; 'checks': 0.30; 'performing': 0.30; 'sense': 0.31; 'code': 0.31; 'point': 0.31; 'asked': 0.33; 'raising': 0.33; 'to:addr:python- list': 0.33; 'operations': 0.33; 'skip:d 20': 0.34; 'received:google.com': 0.34; 'wrong': 0.34; 'third': 0.34; 'fail': 0.35; 'doing': 0.35; 'pm,': 0.35; 'received:209.85.220': 0.35; 'received:209.85': 0.35; 'something': 0.35; 'test': 0.36; 'should': 0.36; 'option': 0.37; 'rather': 0.37; 'received:209': 0.37; 'subject:: ': 0.38; 'perform': 0.38; 'object': 0.38; 'some': 0.38; 'to:addr:python.org': 0.39; 'where': 0.40; 'header:Received:5': 0.40; 'kind': 0.61; 'between': 0.63; 'middle': 0.66; 'potentially': 0.66; '"look': 0.84; '2013': 0.84; 'blow': 0.84; 'complex,': 0.84; 'float,': 0.84; 'number):': 0.84; 'presumably': 0.84; 'to:name:python': 0.84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=pEOAFvlho6qQutbHboNBeFyURhMI4O/MKWD0iCysT2U=; b=MSq+0p1hqpgQtJjbMGUA+U8uYJRsLwD+FFhd7PUk8GvaqXG2voStZ/R2I5Uoz4xnGC AMQachqTO5j9yUuncS+3ZmdAskY3gbBtbpyYNLpRZFGX+GWgcxbGTsD2BqlezfihKY9N Y0S3OYSR/dO0gCKdVwy2rzeLtjhcv1nfVwoy8L4ZgaMnhLhJe3vmQlWG4vIKOCtSHBle 7YlqwY0SkF8HxjSp6ZCTsZZ92wo07IH690NfoOCWHoIpMy+Ln1xIFLF2mIrkkXozyTTP +jL5ARGRN86NTEMWD93S9lMcZmiOb3qvbJva3TR14wRh9FSkLtBeAMI9OqsyGYmCcEci 2OkQ== MIME-Version: 1.0 X-Received: by 10.66.80.68 with SMTP id p4mr57741277pax.35.1360021572137; Mon, 04 Feb 2013 15:46:12 -0800 (PST) In-Reply-To: <5110415c$0$29986$c3e8da3$5496439d@news.astraweb.com> References: <5110415c$0$29986$c3e8da3$5496439d@news.astraweb.com> Date: Mon, 4 Feb 2013 16:46:11 -0700 Subject: Re: LBYL vs EAFP From: Ian Kelly To: Python Content-Type: multipart/alternative; boundary=f46d042ef565b1b3bc04d4eeb25a X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 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: 102 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1360021575 news.xs4all.nl 6849 [2001:888:2000:d::a6]:59344 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:38149 --f46d042ef565b1b3bc04d4eeb25a Content-Type: text/plain; charset=ISO-8859-1 On Feb 4, 2013 4:24 PM, "Steven D'Aprano" < steve+comp.lang.python@pearwood.info> wrote: > > The eternal conflict between "Look Before You Leap" and "Easier to Ask for > Forgiveness than Permission" (LBYL vs EAFP) continues... > > I want to check that a value is a number. Let's say I don't care what sort > of number -- float, int, complex, Fraction, Decimal, something else -- just > that it is a number. Should I: > > Look Before I Leap: > > from numbers import Number > if isinstance(x, Number): > ... > else: > raise TypeError > > > or Ask Forgiveness: > > x + 0 > ... > > > where in both cases the ellipsis ... is the code I actually care about. It seems to me that both of these are LBYL. That the second test checks by trying an operation and potentially raising an exception is immaterial. You're still performing a test prior to attempting the actual operation. > A third option is not to check x at all, and hope that it will blow up at > some arbitrary place in the middle of my code rather than silently do the > wrong thing. I don't like this idea because, even if it fails, it is better > to fail earlier than later. This is what I would consider EAFP. Presumably if the operation requires a number, then it will at some point perform some kind of numerical manipulation that will raise a TypeError if one is not passed. If the operation succeeds, then the object supported all the operations you asked of it, so in what sense would the program be doing the wrong thing? --f46d042ef565b1b3bc04d4eeb25a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Feb 4, 2013 4:24 PM, "Steven D&apos;Aprano" <steve+comp.lang.python@p= earwood.info> wrote:
>
> The eternal conflict between "Look Before You Leap" and &quo= t;Easier to Ask for
> Forgiveness than Permission" (LBYL vs EAFP) continues...
>
> I want to check that a value is a number. Let's say I don't ca= re what sort
> of number -- float, int, complex, Fraction, Decimal, something else --= just
> that it is a number. Should I:
>
> Look Before I Leap:
>
> =A0 =A0 from numbers import Number
> =A0 =A0 if isinstance(x, Number):
> =A0 =A0 =A0 =A0 ...
> =A0 =A0 else:
> =A0 =A0 =A0 =A0 raise TypeError
>
>
> or Ask Forgiveness:
>
> =A0 =A0 x + 0
> =A0 =A0 ...
>
>
> where in both cases the ellipsis ... is the code I actually care about= .

It seems to me that both of these are LBYL. That the second test checks = by trying an operation and potentially raising an exception is immaterial. = You're still performing a test prior to attempting the actual operation= .

> A third option is not to check x at all, and hope that it will blow= up at
> some arbitrary place in the middle of my code rather than silently do = the
> wrong thing. I don't like this idea because, even if it fails, it = is better
> to fail earlier than later.

This is what I would consider EAFP. Presumably if the operation requires= a number, then it will at some point perform some kind of numerical manipu= lation that will raise a TypeError if one is not passed. If the operation s= ucceeds, then the object supported all the operations you asked of it, so i= n what sense would the program be doing the wrong thing?

--f46d042ef565b1b3bc04d4eeb25a--