From: Paul Rubin on
Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes:
> This is why virtually all low-level languages treat 0 as a false ...

OK, but is Python a low-level language, and if not, why are low-level
languages appropriate examples to follow?

>> if myInt <> 0:
>
> I would argue against that. Why do you, the coder, care about the
> specific details of treating ints in a boolean context? The int type
> itself knows, leave the decision to it.

There is a horrible (IMO) thing that Perl, Lua, and Javascript all do,
which is automatically convert strings to numbers, so "12"+3 = 15.
Python has the good sense to throw a type error if you attempt such an
addition, but it goes and converts various types to bool automatically,
which is more Perl-like than I really enjoy. In fact Python 3 added yet
another automatic conversion, of int to float on division, so 1/2 = 0.5.

Obviously it's a point in the design space where various decisions are
possible, but I can get behind the "explicit is better than implicit"
idea and say that none of those conversions should be automatic, and if
1/2 = 0 was confusing people in Python 2 enough to justify changing
divison semantics in Python 3, the preferable change would be for int
division to raise TypeError rather than quietly converting to float.

The same thing goes for bool conversion, though we are all used to it by
now, and it would be way too disruptive a change.

> if myValue.count <= 0 and myValue.next is None and myValue.blob == "":
> # myValue is considered false
> versus:
> if not myValue:
> Which would you prefer?

I'd personally prefer

if not bool(myValue):

which would call the myValue's __bool__ method if it chose to implement
one. Explicit is better than implicit.
From: Ian Kelly on
On Mon, Jul 12, 2010 at 6:18 PM, Steven D'Aprano
<steve(a)remove-this-cybersource.com.au> wrote:
>> I prefere to explicitly write what I want to test:
>>
>> if myInt <> 0:
>
> I would argue against that. Why do you, the coder, care about the
> specific details of treating ints in a boolean context? The int type
> itself knows, leave the decision to it.

I think you're missing the point. He's not using ints in a boolean
context. If it were a boolean context, he would be using bools in the
first place. What he is objecting to is the practice of testing for
special cases of ints (i.e. 0) by treating them as bools. The
specific details of converting ints to bools are very much relevant
here; as long as 0 is false, it works. If -1 is false (a semantic I
have actually seen used), then it does not.

Cheers,
Ian
From: Ian Kelly on
On Mon, Jul 12, 2010 at 6:36 PM, Paul Rubin <no.email(a)nospam.invalid> wrote:
> There is a horrible (IMO) thing that Perl, Lua, and Javascript all do,
> which is automatically convert strings to numbers, so "12"+3 = 15.
> Python has the good sense to throw a type error if you attempt such an
> addition, but it goes and converts various types to bool automatically,
> which is more Perl-like than I really enjoy.  In fact Python 3 added yet
> another automatic conversion, of int to float on division, so 1/2 = 0.5..
>
> Obviously it's a point in the design space where various decisions are
> possible, but I can get behind the "explicit is better than implicit"
> idea and say that none of those conversions should be automatic, and if
> 1/2 = 0 was confusing people in Python 2 enough to justify changing
> divison semantics in Python 3, the preferable change would be for int
> division to raise TypeError rather than quietly converting to float.

I don't think it's any more egregious than automatic conversions of
mixed-type expressions, such as 3 + 4.5. If you don't want your ints
automatically converted to floats on division, then use the integer
division operator. 1 // 2 is still 0 in Python 3.

Cheers,
Ian
From: Paul Rubin on
Ian Kelly <ian.g.kelly(a)gmail.com> writes:
> I don't think it's any more egregious than automatic conversions of
> mixed-type expressions, such as 3 + 4.5.

That could also be explicit: float(3) + 4.5, or 3 + int(4.5).

> If you don't want your ints automatically converted to floats on
> division, then use the integer division operator. 1 // 2 is still 0
> in Python 3.

Sure, I do that, but the issue was that 1/2 was confusing newbies who
don't understand the different characteristics of int and floating
types. If the idea is to change Python to fix this problem in a
newbie-friendly way, the right fix is to create enlightment by raising
an exception that points out the problem, not sweep it under the rug
with an automatic conversion.
From: Cameron Simpson on
On 12Jul2010 17:36, Paul Rubin <no.email(a)nospam.invalid> wrote:
| Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> writes:
| > This is why virtually all low-level languages treat 0 as a false ...
|
| OK, but is Python a low-level language,

Not particularly, but true/false and Boolean login are low level ideas.
If it works well in a low level language (where all you might have are
ints of various flavours and thus some equivalence notion is required),
why would you _change_ the conventions in a high level language without
a compelling reason? The more commonality in concepts there are, for
all that they are just conventions, the easier it is remember how to
do things.

| and if not, why are low-level
| languages appropriate examples to follow?

They may not be in any inherent sense, but they are examples and if the
usage doesn't cause pain are they inappropriate?

Steven:
| >> if myInt <> 0:
| >
| > I would argue against that. Why do you, the coder, care about the
| > specific details of treating ints in a boolean context? The int type
| > itself knows, leave the decision to it.
[...snip...]

This I'm only halfway with. I, the coder, _must_ know. The "if"
statement has an intent, and I need to know that "if myInt:" matches my
intent. Of course, using the right idioms it will match a lot of the
time. But I've certainly been bitten by writing:

if myDict:

intending:

if myDict is not None:

but also getting:

if myDict != {}:

Clearly the fault was mine, but I, the coder, _must_ care about the
details of using non-Booleans in a Boolean context.

Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

It is Texas law that when two trains meet each other at a railroad crossing,
each shall come to a full stop, and neither shall proceed until the other has
gone.