LBYL vs EAFP

[Dave Angel]

On 02/04/2013 06:38 PM, Chris Angelico wrote:
> On Tue, Feb 5, 2013 at 10:16 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>> 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.
>>
>> Comments, thoughts and opinions please.
>
> It depends on what could cause the failure. If only a programming
> error could cause x to not be a number, I'd go with your third option
> - let it blow up anywhere, and follow the trace. That option requires
> zero forethought, which translates directly into programmer
> efficiency. But if x came from a user,  then I'd be checking inputs at
> a much earlier point.
>
> Those are the two obvious cases though, and I'm assuming your
> situation is neither of them. Writing library code is half way in
> between. With the specific examples given, I wouldn't like to use "x +
> 0" as a check; it seems dodgy. Firstly because it doesn't look like a
> data type check (though a comment can help with that), and secondly
> because something might very well support having a number added to it
> while definitely not itself being a number - eg something along the
> lines of a database cursor. So I would recommend LBYL for this
> particular case.
>
> ChrisA
>

I agree with Chris.  It would seem that the main purpose of the abc 
numbers.Number is for this.  See the page:

http://docs.python.org/2/library/numbers.html
   "If you just want to check if an argument x is a number, without 
caring what kind, use isinstance(x, Number)."

But the real question is "what is a number?" .   You used lowercase in 
your description, so you weren't defining it as the particular classes 
that were already associated with Number.  I expect you're using Python 
3, which you should have specified.  If so, I'd tend to replace the x+0 
with x > 0    which would be an error for any class other than int which 
didn't define the corresponding dunder operators.


Coincidentally, that's the next question you asked.  So if you're only 
interested in values that are positive, that would seem to be clearer.

Unfortunately, that test would raise a TypeError for complex values.



-- 
DaveA