Velocity Reviews > integer >= 1 == True and integer.0 == False is bad, bad, bad!!!

# integer >= 1 == True and integer.0 == False is bad, bad, bad!!!

rantingrick
Guest
Posts: n/a

 07-11-2010
Let me tell you folks about a recent case of culo rojo i experianced
whilst creating a customized bin packer with Python. First i want to
say that i actually like the fact that i can do this..

py> a = []
py> if a:
.... do something

py> if len(a) > 0:
.... do something

Ok but the buck stops with integers. Why? you ask in amazing
befuddlement...Well I happened upon this atrocity when creating
variables that hold indexes into a python list. the variables where
named "choice1 and choice2 and both where initialized to None. Fine no
problem there. So the algorithm will search for the two best choices.
The first choice "choice1" will always be array[0]. The second choice
"choice2" will need to be found using a completely different
algorithm. ...Well i could tell you about it but i would rather just
show you with some simple code..

array = [c1,c2,c3,c4,c5,c6,...]
while looping:
choiceIdx1 = None
choiceIdx2 = None
if array[0] meets condition this condition:
choiceIdx1 = 0
for i in range(len(array)):
if array[i] meets this condition:
choiceIdx2 = i
break
if choiceIdx1 and not choiceIdx2:
best = array.pop(choiceIdx1)
elif choiceIdx2 and not choiceIdx1:
best = array.pop(choiceIdx2)
elif choiceIdx1 and choiceIdx2:
# figure out which choice is better.
best = choiceIdx1 if choiceIdx1.better() else choiceIdx2
elif not choiceIdx1 and not choiceIdx2:
break
else:
# assume the worst
raise
do_somthing_with(best)

BUT THAT WONT WORK BECAUSE OF CRAPPY INTEGER BOOLEAN DEFAULTS! So i
had to do this crap...!

array = [c1,c2,c3,c4,c5,c6,...]
while looping:
choiceIdx1 = ()
choiceIdx2 = ()
if array[0] meets condition this condition:
choiceIdx1 = (0,)
for i in range(len(array)):
if array[i] meets this condition:
choiceIdx2 = (i,)
break
if choiceIdx1 and not choiceIdx2:
best = array.pop(choiceIdx1[0])
elif choiceIdx2 and not choiceIdx1:
best = array.pop(choiceIdx2[0])
elif choiceIdx1 and choiceIdx2:
# figure out which choice is better.
best = choiceIdx1[0] if choiceIdx1.better() else choiceIdx2[0]
elif not choiceIdx1 and not choiceIdx2:
break
else:
# assume the worst
raise
do_somthing_with(best)

Seems kinda dumb to build a tuple just so a conditional wont blow
chunks! This integer bool-ing need to be fixed right away!

Stephen Hansen
Guest
Posts: n/a

 07-11-2010
On 7/10/10 10:38 PM, rantingrick wrote:
> Seems kinda dumb to build a tuple just so a conditional wont blow
> chunks! This integer bool-ing need to be fixed right away!

Yes, let us penalize the thousands of use cases where 0 being false is
useful and good, for the benefit of the one use-case (indexing) where it
is not.

You don't need to build a tuple. Just change the tests, to "if
choiceIdx1 is not None". Its a little more work, sure. But its not
enough that its even vaguely worth breaking the otherwise very useful
behavior of bool(0) == False.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMOVv6AAoJEKcbwptVWx/lhxkIAKJ8iANPmgJoZcCRwZNl7dDg
llotQF+gzaKE4v6/dcsS0jnKh/uGQfaP9nAE/wxUjmMp37CghKesQSVCzc55FJM+
O2Pl1r7u8K1pJcnthg8KUSO5Jh2e1N7bObWuyHGMtt/SdaTqR2BdC5pKmJRlr1Jb
LtRKH/jIgrhoStDXzdiTI8vqm30oB5KcB96su3eNwb9cxvoOia9bnUbP Qu4Be00M
U6Rl8J6dMWXk8sZdtjFJGCijFX3gDOjLgjzJ2GVU/iG5IC1lnqH+Zy+zVSmoK28=
=mDNt
-----END PGP SIGNATURE-----

rantingrick
Guest
Posts: n/a

 07-11-2010
On Jul 11, 12:51*am, Stephen Hansen <me+list/(E-Mail Removed)> wrote:

> You don't need to build a tuple. Just change the tests, to "if
> choiceIdx1 is not None". Its a little more work, sure. But its not
> enough that its even vaguely worth breaking the otherwise very useful
> behavior of bool(0) == False.

Hmm, i beg to differ. The if choice1 is not None and choice2 is not
None is going to run off my screen and into my neighbors backyard
swimming pool!

If you *can* Stefen, show the class a "very useful" case for integer
bool-ing? Please do so, although i doubt you can offer one. Maybe
you'll offer this kinda kludgy stuff...

function(option=1) #instead of True
function(option=0) #instead of False

This is another example of the damage integer booling does to your
code and your mind. What happened to explicit is better than implicit?
What happened to tim toady is a SOB! It is easy to get drawn into this
way of coding and very hard to pull out. And it's wrong, wrong, wrong.
NEVER substitute 1 for True and/or 0 for False! NEVER! This is anti
Pythonic!

py> import this

Stephen Hansen
Guest
Posts: n/a

 07-11-2010
On 7/10/10 11:03 PM, rantingrick wrote:
> On Jul 11, 12:51 am, Stephen Hansen <me+list/(E-Mail Removed)> wrote:
>
>> You don't need to build a tuple. Just change the tests, to "if
>> choiceIdx1 is not None". Its a little more work, sure. But its not
>> enough that its even vaguely worth breaking the otherwise very useful
>> behavior of bool(0) == False.

>
>
> Hmm, i beg to differ. The if choice1 is not None and choice2 is not
> None is going to run off my screen and into my neighbors backyard
> swimming pool!

"if choiceIdx1 is not None and choiceIdx2 is not None:" is 54
characters. Your straw man argument fails. Even if this is in a method
of a class, that's only 64; even with another two levels of indentation
it still isn't longer then the 80 which is where some people consider
things "long" (I do not: I don't mind code > 100).

If you are so desperately concerned with space, then simply do:

if (choiceIdx1, choiceIdx2) != (None, None):

Its only eleven characters longer.

Or, you can do:

if None not in (choiceIdx1, choiceIdx2):

Its only two characters. You really can't honestly be making an argument

> If you *can* Stefen,

My name is Stephen. This is the second time you've done this: if you
can't show even the vaguest respect and actually use my name and not a
mockery of it, then I'll just killfile you.

> show the class a "very useful" case for integer
> bool-ing? Please do so, although i doubt you can offer one. Maybe
> you'll offer this kinda kludgy stuff...
>
> function(option=1) #instead of True
> function(option=0) #instead of False

Of course I won't offer that. If I wish a boolean flag, something which
can have only one of two states (although sometimes a three-state
'maybe' is useful, with None being the 'neither true nor false'), I'd
use the boolean.

There's numerous cases where "if x" where x is an integer is useful. A
counter is the simplest example. Say you're counting how many
watermelons are in your inventory there is, and you want to test if
there's any or not. "if watermelons" is the concise, readable,
understandable way to express this. Readability counts.

A boolean test in Python tests "something" verses "nothing", it doesn't
test Truth verses False

It is entirely consistent in this regard (except in the case of custom
classes which may decide to do strange things).

Zero is, clearly, nothing.

> This is another example of the damage integer booling does to your
> code and your mind.

Utter nonsense. No one does that unless they are coming from C or some
other language without a True/False and don't know about it, or if they
are using a codebase which is supporting a very old version of Python
before True or False were introduced.

But you're just going to argue endlessly, no doubt. Have you ever
actually considered the fact that your gut reaction might, I don't know,
be wrong or misguided? I've admitted when I'm wrong on more then one
occasion.

I really don't know why I bother.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMOWMjAAoJEKcbwptVWx/l+LUH/jjshk3CGhf+WMAoF5EHq1n1
bz7B2s9F0PovGMmy76IoxHU585TuxWN8tBXWaPjozYmIOVZSzd 4t1sNxmobw/mXT
3kMfgzQBs+VJmlf7Y9ywJoZhhGoRwbfcgN95hYu1SIX41TRsK3 osWVkTPZu/0kWJ
r8dsqDopajWG+ysnLBhG14aWePDqRYQTZA7+WlFdjrlHJWz2ee UsqCqIUfR8TSZ0
R+F5qosmjXI8EzZPWyKgITzeJ/s2jFe9Bd9T1A3k3AHhX6omPBWXYTu6n9yjtUfX
8V7DG6qmuRwQ1Fv7EwKWb2eC7vhl+PRAT9WZ37w8wOyUwCy1Cy HK4r2FK8oAvKs=
=32Ci
-----END PGP SIGNATURE-----

rantingrick
Guest
Posts: n/a

 07-11-2010
On Jul 11, 1:22*am, Stephen Hansen <me+list/(E-Mail Removed)> wrote:

> If you are so desperately concerned with space, then simply do:
>
> * * if (choiceIdx1, choiceIdx2) != (None, None):
>
> Its only eleven characters longer.
>
> Or, you can do:
>
> * * if None not in (choiceIdx1, choiceIdx2):

Only the first example was worse than the second. You do realize that
Python must build a tuple for ever conditional that uses this
semantic? This is more bad, bad, bad than integer bool-ing! My bin
packer could potentially compute millions of parts. I do not want to
waste valuable processor cycles building numerous tuples just for the
sake of a conditional "condition"! This is bad coding style Stephen.

> Its only two characters. You really can't honestly be making an argument
> about two characters.
>
> > If you *can* Stefen,

>
> My name is Stephen.

It was a typo not an on purpose misspelling

> Of course I won't offer that. If I wish a boolean flag, something which
> can have only one of two states (although sometimes a three-state
> 'maybe' is useful, with None being the 'neither true nor false'), I'd
> use the boolean.

I agree... True, False, None. The trinity of bool-inity.

> There's numerous cases where "if x" where x is an integer is useful. A
> counter is the simplest example. Say you're counting how many
> watermelons are in your inventory there is, and you want to test if
> there's any or not. "if watermelons" is the concise, readable,
> understandable way to express this. Readability counts.

I agree but when in a conditional bool(integer) should be forced.
Look, don't try to shoove this under the mattress like nobody
initializes a variable to None and then maybe or maybe not stores an
array index in the variable and then later needs to test for true
false in a conditional. It's very common to initialize a counter or
index variable to None or 0. And later you don't want 0 and None bool-
ing to False and range(1:infinity)+range(-infinity:-1) bool-ing to
True!

> A boolean test in Python tests "something" verses "nothing", it doesn't
> test Truth verses False
>
> It is entirely consistent in this regard (except in the case of custom
> classes which may decide to do strange things).
>
> Zero is, clearly, nothing.

No ****! i am talking about CONDITIONALS HERE. Specifically
CONDITIONALS and BOOL-ING!

> Utter nonsense. No one does that unless they are coming from C or some
> other language without a True/False and don't know about it, or if they
> are using a codebase which is supporting a very old version of Python
> before True or False were introduced.

Ah yes, when nothing else seems to work fall back to you default
programming... FUD and ad hominem
attacks

> But you're just going to argue endlessly, no doubt. Have you ever
> actually considered the fact that your gut reaction might, I don't know,
> be wrong or misguided? I've admitted when I'm wrong on more then one
> occasion.

I have no problem admitting when i wrong. In this case however i am
completely right. Use True/False for bool-ing, None for emptyness, and
integers for inetgers.

Ian Kelly
Guest
Posts: n/a

 07-11-2010
On Sun, Jul 11, 2010 at 12:03 AM, rantingrick <(E-Mail Removed)> wrote:
> This is another example of the damage integer booling does to your
> code and your mind. What happened to explicit is better than implicit?

Explicit is better than implicit. Hence, if you're specifically
testing for the property of not being None rather than for the more
general truth value, it's better to write "if choiceIdx1 is not None"
rather than just "if choiceIdx". This holds true for empty
collections as well.

On Sun, Jul 11, 2010 at 12:22 AM, Stephen Hansen
<me+list/(E-Mail Removed)> wrote:
> There's numerous cases where "if x" where x is an integer is useful. A
> counter is the simplest example. Say you're counting how many
> watermelons are in your inventory there is, and you want to test if
> there's any or not. "if watermelons" is the concise, readable,
> understandable way to express this. Readability counts.

I would also point out that the current semantics mean that
"bool(container)", "bool(len(container))", and "len(container) > 0"
are all equivalent. I view this as a positive thing.

It also means that "if integer" in Python and "if (the_same_integer)"
in a C module have the same semantics. It would be a nasty surprise
for writers of C modules if they didn't.

And I think that partly this is simply historical. Before a proper
boolean type was added to Python, 1 and 0 were the norm for storing
truth values. Changing the truth value of 0 when bools were
introduced would have broken tons of existing code. This is also the
reason why bool is a subclass of int.

Ian Kelly
Guest
Posts: n/a

 07-11-2010
On Sun, Jul 11, 2010 at 12:57 AM, Ian Kelly <(E-Mail Removed)> wrote:
> And I think that partly this is simply historical. *Before a proper
> boolean type was added to Python, 1 and 0 were the norm for storing
> truth values. *Changing the truth value of 0 when bools were
> introduced would have broken tons of existing code. *This is also the
> reason why bool is a subclass of int.

Another thought related to that list bit: if bool(0) were True, then
bool(int(False)) would also be True. That seems messed up. Then
again, bool(str(False)) is already True. Does that bother anybody
other than me?

Stephen Hansen
Guest
Posts: n/a

 07-11-2010
On 7/10/10 11:50 PM, rantingrick wrote:
> On Jul 11, 1:22 am, Stephen Hansen <me+list/(E-Mail Removed)> wrote:
>
>> If you are so desperately concerned with space, then simply do:
>>
>> if (choiceIdx1, choiceIdx2) != (None, None):
>>
>> Its only eleven characters longer.
>>
>> Or, you can do:
>>
>> if None not in (choiceIdx1, choiceIdx2):

>
>
> Only the first example was worse than the second. You do realize that
> Python must build a tuple for ever conditional that uses this
> semantic? This is more bad, bad, bad than integer bool-ing! My bin
> packer could potentially compute millions of parts. I do not want to
> waste valuable processor cycles building numerous tuples just for the
> sake of a conditional "condition"! This is bad coding style Stephen.

Nonsense.

Prove it. Show actual benchmarks and actual problems to that style.

Tests that do, in essence, "if whatever in (constant1, constant2)" are
exceedingly common. The burden is on you to prove they are bad. With
real data.

>
>> Its only two characters. You really can't honestly be making an argument
>> about two characters.
>>
>>> If you *can* Stefen,

>>
>> My name is Stephen.

>
> It was a typo not an on purpose misspelling

If this had been the first time, perhaps. If you had not in *numerous*
previous times spelled my name correctly, perhaps. If it were at all
possible for "f" to be a typo of "ph", perhaps.

As none of those are true, I must assume you are simply trying to be
insulting.

And yes, I do consider mangling my name to be an insult.

>> There's numerous cases where "if x" where x is an integer is useful. A
>> counter is the simplest example. Say you're counting how many
>> watermelons are in your inventory there is, and you want to test if
>> there's any or not. "if watermelons" is the concise, readable,
>> understandable way to express this. Readability counts.

>
> I agree but when in a conditional bool(integer) should be forced.

Uh, what? I left off the rest of this paragraph because it is
incomprehensible.

If bool(anything_at_all) returns True, then "if anything_at_all" must
succeed. If bool(anything_at_all) returns False, then "if
anything_at_all" must fail.

To do otherwise would create two entirely different and strange
definitions for what is Truth and what is False. Python defines them
very clearly. Something. Verses. Nothing.

1 is something.

0 is nothing.

>> A boolean test in Python tests "something" verses "nothing", it doesn't
>> test Truth verses False
>>
>> It is entirely consistent in this regard (except in the case of custom
>> classes which may decide to do strange things).
>>
>> Zero is, clearly, nothing.

>
> No ****! i am talking about CONDITIONALS HERE. Specifically
> CONDITIONALS and BOOL-ING!

I, too, am speaking of conditionals here. No **** back at you.

The "if" statement works on the test, "Is this something?" If so, it
executes its body. If not, it executes the 'else' body if present.

>> Utter nonsense. No one does that unless they are coming from C or some
>> other language without a True/False and don't know about it, or if they
>> are using a codebase which is supporting a very old version of Python
>> before True or False were introduced.

>
> Ah yes, when nothing else seems to work fall back to you default
> programming... FUD and ad hominem
> attacks

Red herring.

Do you know what FUD is?

FUD is Fear, Uncertainty, and Doubt. I didn't try to scare you about
anything. I didn't try to make you uncertain if something would work.
And so on, and so forth.

I dismissed your utterly unfounded claim and example which you held up
as proof of your central point as nonsense.

Do you know what an ad hominem attack is? I didn't say, "Your argument
is invalid because you, a jackass, said it" -- that would be an ad
hominem attack.

My statement is neither FUD, nor even an ad hominem attack. If you
dispute my dismissal, show evidence. Any will do.

Oh, I do admit that in the end, I did venture into the ad hominem area
where I called into question your attitude and general behavior of utter
Infallible Rightness and trolling tendencies, but that is not a logical
fallacy. You can call into question the motives and character of a
person -- provided you are not using this as the sole means of denying
their claim. You can't simply sweep my argument aside by claiming its an
ad hominem attack because besides my pointing out you're trollish
behavior, I'm actually taking the time to refute your actual arguments
with arguments of my own.

>> But you're just going to argue endlessly, no doubt. Have you ever
>> actually considered the fact that your gut reaction might, I don't know,
>> be wrong or misguided? I've admitted when I'm wrong on more then one
>> occasion.

>
> I have no problem admitting when i wrong.

Please, show an example.

> In this case however i am
> completely right. Use True/False for bool-ing, None for emptyness, and
> integers for inetgers.

Nonsense.

None is not "for emptiness".

None is a discrete entity, which exists for a very specific purpose. It
evaluates as false, certainly. But it is neither the definition nor the
poster child of emptiness.

It is something else entirely. It is None. It is "no value" -- not the
absence of a value, nor the absence of any thing, but the discrete state
of "I explicitly have no value". That is *very* different, and very
powerful, from the simple state of "empty". Many things can be empty.
Many things can be nothing.

Emptiness is far, far more then None.

"" is emptiness, too. {} is emptiness, too. () is emptiness, too. [] is
emptiness, too.

And, 0 is emptiness, too. As is 0.0, though this is less useful (Since
floating point math gets weird).

Do you see the pattern? Every fundamental data type has a "nothing"
state: and they ALL evaluate as false in conditionals.

Why should integers be any different? Because, uh, you say so.

Okay.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJMOXByAAoJEKcbwptVWx/lJBsIAJ5D5ZnRjTLGyIhar8gIHMCa
o/9D44M9Pz02MHY62Wi4owKRoHtec9flOlHBeeMTTqSYetaQfDvG BO5zEB23QE5D
eGyXK7LFtU2/QU9mPyNqu1QAXG2BDy0Wk8WhE5EesB0vqJwJau36IYs/0IlrhOXX
g1dB73TYKYWMD0QBm9jVWz9D4OJuYtxbNHeHu1lPm2IPcISVPj +NaPdFfbEgVjQH
9xqVQUozKexZpdx8YpuVkyR7v4CusNG8W0zp6pRPSQKecoUh9o YrDbk/HqyMYzX7
cXl1dR5M5rLBLtHvqgRE2eiXH6oN6TDZltgP87woCMZBljBF6U KSvZ2f3lkHpd0=
=mpUx
-----END PGP SIGNATURE-----

Alf P. Steinbach /Usenet
Guest
Posts: n/a

 07-11-2010
* Stephen Hansen, on 11.07.2010 09:19:
> On 7/10/10 11:50 PM, rantingrick wrote:
>>
>> It was a typo not an on purpose misspelling

>
> If this had been the first time, perhaps. If you had not in *numerous*
> previous times spelled my name correctly, perhaps. If it were at all
> possible for "f" to be a typo of "ph", perhaps.

It is a natural mistake to make in some languages. E.g. in Norwegian the Devil
can be spelled Faen or Fanden (modern) or Phanden (old-fashioned, no longer in
dictionaries but still used to sort of tone down the expression). It's even
there in English, like "file" and "philosophy". So it's an error committed not
by the limbic system but by a slightly higher level sound-to-text translator
brain circuit. The text is generated from how the word sounds in one's head.

Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

Paul Rubin
Guest
Posts: n/a

 07-11-2010
rantingrick <(E-Mail Removed)> writes:
> unspeakably ugly code.

I'd write the code differently to not do all those branches.
I like to use 1-elemnt lists as an option type, instead of using None,
so you can just concatenate them together to get the first non-empty
one. Untested code:

array = [c1,c2,c3,c4,c5,c6,...]

# return first element of iterable that matches condition, wrapped
# as a 1-element list. If no match, return empty list.
def xfind(condition, iterable):
for x in iterable:
if condition(x): return [x]
return []

while looping:
cs = xfind(this_condition, array) + xfind(other_condition, array)
# cs is now a list of either zero, one, or two matching elements
if len(cs) == 1:
r = cs[0]
elif len(cs) = 2:
r = <whichever is best>
else:
break
best = array.pop(r)
do_somthing_with(best)

Obviously you can golf the above in various ways.

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post bdb112 Python 45 04-29-2009 02:35 AM André ASP .Net 3 08-28-2006 12:02 PM Nick Computer Security 3 04-26-2006 07:40 PM Pierre Quentel Python 59 12-16-2005 01:47 PM Siemel Naran C++ 19 06-18-2004 11:06 AM