Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!news.mixmin.net!eweka.nl!hq-usenetpeers.eweka.nl!xlned.com!feeder7.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <511081e3$0$21856$c3e8da3$76491128@news.astraweb.com>
References: <5110415c$0$29986$c3e8da3$5496439d@news.astraweb.com> <mailman.1338.1360021130.2939.python-list@python.org> <511081e3$0$21856$c3e8da3$76491128@news.astraweb.com>
Date: Tue, 5 Feb 2013 16:19:20 +1100
Subject: Re: LBYL vs EAFP
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1349.1360041568.2939.python-list@python.org>
Lines: 52
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:38162

On Tue, Feb 5, 2013 at 2:52 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 05 Feb 2013 10:38:41 +1100, Chris Angelico wrote:
>
>> On Tue, Feb 5, 2013 at 10:16 AM, Steven D'Aprano
>> <steve+comp.lang.python@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.
> [...]
>
>> 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
>
> Strange. To me, it looks like "oh, you're testing whether x supports
> numeric addition". I suppose the hidden assumption I'm making is that if
> x supports addition, it is a kind of number. Perhaps that's an unsafe
> assumption.

If your code bombs and the exception traceback shows a line saying "x
+ 0", I'm going to wonder if it's a massive bug... or, worse, if
you're expecting x.__add__() to have stupid side effects ("yeah,
adding 0 to x turns x into a float, but subtracting 0 from it forces
it to be an int").

>> (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.
>
> But surely duck-typing tells us that if database cursors support the same
> sort of operations that numbers support, we should therefore treat them
> as a kind of number?

Depends what operations you mean. It's not uncommon for a
cursor/iterator object to support "x+=1" to move to the next
row/element/whatever; if your result set is maintained elsewhere, you
could cheaply support "x + 4" to create a new iterator that's four
rows further along. But in all other respects, it's not a number. You
can't multiply an iterator by 2, for instance.

> My library will not try to prevent the caller taking the average of (say)
> a dozen eggs and 10 miles. I'm not sure that it should try to prevent the
> caller from trying to take the average between two database cursors.

Well, sure... if your code is so simple and trivial, and if the
cursors support "x - y" to get the number of rows between them. But in
that case, go for true EAFP and eschew error checking altogether.

ChrisA