Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Sun, 15 Jul 2012 11:56:49 -0700 (PDT)
In-Reply-To: <mailman.2148.1342375350.4697.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=166.249.198.115; posting-account=h3aEwQoAAACiuqX-oR3gvCVFm8lLHoWj
References: <mailman.2132.1342341291.4697.python-list@python.org> <5002a1f9$0$29995$c3e8da3$5496439d@news.astraweb.com> <mailman.2141.1342369188.4697.python-list@python.org> <7b027612-a07e-40f9-8ad2-3e95c5440482@googlegroups.com> <mailman.2148.1342375350.4697.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: Implicit conversion to boolean in if and while statements
From: Rick Johnson <rantingrickjohnson@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Message-ID: <mailman.2150.1342378612.4697.python-list@python.org>
Lines: 67
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:25366

On Sunday, July 15, 2012 1:01:58 PM UTC-5, Ian wrote:

> So now instead of having to understand how "if" handles arbitrary
> values, we have to understand how "bool" handles arbitrary values.
> How is that an improvement?

Because we are keeping the condition consistent. We are not relying on impl=
icit resolution of an object's value based on some dark, esoteric and incon=
sistent rules that defy all normal logic.

> What should "if" do if presented a value that isn't True or False?
> Raise a TypeError?

YES! Because IT IS the author's responsibility to present a condition that =
evaluates to either True or False. Anything else would be ridiculously inco=
nsistent.

> Next thing we know, people get so used to wrapping everything they
> present to "if" in a "bool()" call, that they start writing silly
> things like "if bool(x =3D=3D 7)" and "if bool(isinstance(x, int))". =20

We cannot prevent morons from doing stupid things. "x=3D=3D7" IS an explici=
t statement that evaluates to either True or False. Likewise, isinstance(ob=
j, type) is a function that evaluates to either True or False. Wrapping eit=
her example in a bool call is redundant and only obfuscates the meaning. Tr=
ue equals True and False equal False. Why do you need to test that truth?

The only time you will be forced to use the bool is when you are NOT using =
rich comparisons or NOT using truth testing functions in a condition. The f=
ollowing require NO bool function:

obj =3D=3D obj -> bool
obj !=3D obj -> bool
obj > obj -> bool
obj < obj -> bool
obj >=3D obj -> bool
obj <=3D obj -> bool
isinstance(obj, type) -> bool
callable(obj) -> bool
hasattr(obj, name) -> bool
issubclass(obj, name) -> bool
..along with any function that returns a bool

Whereas:=20
"if obj" -> Some esoteric semantics that defies all logic!

> Why?
> Because it's faster and easier to automatically wrap the value in
> "bool" than it is to put in the effort to verify that the value will
> always be a bool to begin with in order to avoid a useless and
> annoying exception. =20

No, because we want our code to be EXPLICIT and consistent! Remember, writi=
ng obfuscated code is easy, however, interpreting obfuscated code is diffic=
ult! A good measure of your programming skill is to see how easily your cod=
e is read by the majority.=20

 """If it's difficult to explain, it's probably a bad idea""".=20

"if blah" is difficult to explain, whereas "if bool(blah)" is not.  =20

> At the point that happens, the "bool()" is
> effectively just part of the if syntax, and we're back to where we
> started.

That's a ridiculous conclusion. See points above^^^