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

[Stephen Hansen]

On 7/10/10 11:50 PM, rantingrick wrote:
> On Jul 11, 1:22 am, Stephen Hansen <me+list/pyt... at ixokai.io> 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 shit! i am talking about CONDITIONALS HERE. Specifically
> CONDITIONALS and BOOL-ING!

I, too, am speaking of conditionals here. No shit 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20100711/4de89c1a/attachment.sig>