Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38172

Re: LBYL vs EAFP

Show key headers only | View raw

On 2/4/2013 6:16 PM, Steven D'Aprano wrote:
> The eternal conflict between "Look Before You Leap" and "Easier to Ask for
> Forgiveness than Permission" (LBYL vs EAFP) continues...

A somewhat different answer is that it depends on what you want the 
function to do, as documented and *tested*. And that partly depends on 
whether it is educational code for humans, production app code, or 
library code.

The test driven approach would be to write tests and then do what is 
needed to get them to pass. Doctests, unittests, and my private function 
test functions allow testing for raising a particular exception. 
AssertRaises() is used, perhaps increasingly, in stdlib tests. The 
absence of any tests for the response to 'bad' input suggests that the 
responses are 'undefined'.

That said, I admit that Python's extensible class system makes bad-input 
testing harder. I also think that anyone who uses non-builtin classes 
outside of their intended use area has to take responsibility.

For instance:

def f(n, a):
   if n < 0: raise ValueError('n cannot be negative')
   b = 0
   while n:
     b = process(a, b)
     n -= 1

looks like a safe LBYL function. But suppose n is an instance of a class 
that perversely implements subtraction as addition (or as doing 
nothing). Algorithm termination is based on the presumption that 
'decrementing' a 'positive value' moves it 'toward 0' and can only be 
done a finite number of times. Verifying that an input is a member of 
that abstract class is not trivial ;-).

 > 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.

A silent infinite loop is bad. Infinite recursion stopped with the 
recursion limit check is less bad.

If tests pass with no check, then nothing need be done until one moves 
from correctness to resource use.

-- 
Terry Jan Reedy

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

LBYL vs EAFP Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-05 10:16 +1100
  Re: LBYL vs EAFP Chris Angelico <rosuav@gmail.com> - 2013-02-05 10:38 +1100
    Re: LBYL vs EAFP Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-05 03:52 +0000
      Re: LBYL vs EAFP Chris Angelico <rosuav@gmail.com> - 2013-02-05 16:19 +1100
  Re: LBYL vs EAFP Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-04 16:46 -0700
    Re: LBYL vs EAFP Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-05 04:52 +0000
      Re: LBYL vs EAFP Chris Angelico <rosuav@gmail.com> - 2013-02-05 16:20 +1100
        Re: LBYL vs EAFP Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-05 06:31 +0000
          Re: LBYL vs EAFP Pete Forman <petef4+usenet@gmail.com> - 2013-02-05 09:49 +0000
            Re: LBYL vs EAFP Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-05 23:04 +1100
              Re: LBYL vs EAFP Chris Angelico <rosuav@gmail.com> - 2013-02-05 23:25 +1100
      Re: LBYL vs EAFP Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-04 22:40 -0700
  Re: LBYL vs EAFP Dave Angel <davea@davea.name> - 2013-02-04 18:55 -0500
  Re: LBYL vs EAFP Chris Angelico <rosuav@gmail.com> - 2013-02-05 11:45 +1100
  Re: LBYL vs EAFP Ethan Furman <ethan@stoneleaf.us> - 2013-02-04 16:26 -0800
  Re: LBYL vs EAFP Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-02-05 01:00 +0000
  Re: LBYL vs EAFP Terry Reedy <tjreedy@udel.edu> - 2013-02-05 02:53 -0500

csiph-web