Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <54afc949$0$12985$c3e8da3$5496439d@news.astraweb.com>
References: <54ABB88A.7070504@r3dsolutions.com> <54ABC52A.1050507@davea.name> <54ABE383.3020801@r3dsolutions.com> <54ABEAD9.8070000@davea.name> <mailman.17424.1420596200.18130.python-list@python.org> <54ace9f0$0$2738$c3e8da3$76491128@news.astraweb.com> <87tx02gb9d.fsf@elektro.pacujo.net> <54adc53c$0$12999$c3e8da3$5496439d@news.astraweb.com> <877fwx3i8f.fsf@elektro.pacujo.net> <CALwzidkn5E3uxQ3Et9r-0_WUTjPLfHtY7mqwnhNVe2MGCi528Q@mail.gmail.com> <mailman.17483.1420742711.18130.python-list@python.org> <54afc949$0$12985$c3e8da3$5496439d@news.astraweb.com>
Date: Fri, 9 Jan 2015 23:43:42 +1100
Subject: Re: Comparisons and sorting of a numeric class....
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.17524.1420807429.18130.python-list@python.org>
Lines: 40
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:83437

On Fri, Jan 9, 2015 at 11:27 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Chris Kaynor wrote:
>
>> Lately, I've been doing quite a bit of work in lua, and many times have
>> wished that empty strings, tables, and 0 acted "falsey", but at the same
>> time, previously working in Python, there were plenty of times I wished
>> they acted "truthy". It merely depends on what algorithm I am using at the
>> time...
>
>
> Please do elaborate. I've never found myself in a situation where I have
> wanted empty containers to be truthy, and I can't think of what such a
> situation would be like.

It's a matter of what you're comparing against. If you might have a
thing and might not, the obvious way to arrange things is to have the
thing be true and the non-thing be false. That works nicely if that
"thing" is an object that's always True, and the "non-thing" is None;
for instance, I might have a socket object, and I might not, so I can
use "if not self.socket: self.connect()" to ensure that I have one
(assuming that self.connect() will throw an error if it fails to
establish, blah blah, handwave away the details). This does NOT work
if a socket object might be false, so I'd have to explicitly check "if
self.socket is None:". Similarly, there are times when the user might
have entered a string or might not - say you have an optional
parameter "--name" which, if omitted, defaults to some sort of
arbitrarily-assigned name; to distinguish between "--name=" and not
providing that parameter at all, the logical way is to have name be
either a string or None. Again, "if name" would make good sense as
meaning "if the --name parameter was provided", rather than "if the
--name parameter was provided and not the empty string". If it helps,
think of a "nullable field" in databasing.

Python's truthiness model is pretty consistent (apart from a few
oddities like midnight being false), so I'm not advocating making this
change. I'm just explaining the case where the opposite choice does
make sense.

ChrisA