Discussion in 'Python' started by rantingrick, Jul 11, 2010.

1. ### rantingrickGuest

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 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

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 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!

rantingrick, Jul 11, 2010

2. ### Stephen HansenGuest

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/jIgrhoStDXzdiTI8vqm30oB5KcB96su3eNwb9cxvoOia9bnUbPQu4Be00M
U6Rl8J6dMWXk8sZdtjFJGCijFX3gDOjLgjzJ2GVU/iG5IC1lnqH+Zy+zVSmoK28=
=mDNt
-----END PGP SIGNATURE-----

Stephen Hansen, Jul 11, 2010

3. ### rantingrickGuest

On Jul 11, 12:51 am, Stephen Hansen <me+list/> 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...

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

rantingrick, Jul 11, 2010
4. ### Stephen HansenGuest

On 7/10/10 11:03 PM, rantingrick wrote:
> On Jul 11, 12:51 am, Stephen Hansen <me+list/> 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...
>

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

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
bz7B2s9F0PovGMmy76IoxHU585TuxWN8tBXWaPjozYmIOVZSzd4t1sNxmobw/mXT
3kMfgzQBs+VJmlf7Y9ywJoZhhGoRwbfcgN95hYu1SIX41TRsK3osWVkTPZu/0kWJ
r8dsqDopajWG+ysnLBhG14aWePDqRYQTZA7+WlFdjrlHJWz2eeUsqCqIUfR8TSZ0
R+F5qosmjXI8EzZPWyKgITzeJ/s2jFe9Bd9T1A3k3AHhX6omPBWXYTu6n9yjtUfX
8V7DG6qmuRwQ1Fv7EwKWb2eC7vhl+PRAT9WZ37w8wOyUwCy1CyHK4r2FK8oAvKs=
=32Ci
-----END PGP SIGNATURE-----

Stephen Hansen, Jul 11, 2010
5. ### rantingrickGuest

On Jul 11, 1:22 am, Stephen Hansen <me+list/> 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
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
>
> > 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 shit! 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
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.

rantingrick, Jul 11, 2010
6. ### Ian KellyGuest

On Sun, Jul 11, 2010 at 12:03 AM, rantingrick <> 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/> 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, Jul 11, 2010
7. ### Ian KellyGuest

On Sun, Jul 11, 2010 at 12:57 AM, Ian Kelly <> 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?

Ian Kelly, Jul 11, 2010
8. ### Stephen HansenGuest

On 7/10/10 11:50 PM, rantingrick wrote:
> On Jul 11, 1:22 am, Stephen Hansen <me+list/> 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
> 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
>>
>>> 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.

> 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/9D44M9Pz02MHY62Wi4owKRoHtec9flOlHBeeMTTqSYetaQfDvGBO5zEB23QE5D
eGyXK7LFtU2/QU9mPyNqu1QAXG2BDy0Wk8WhE5EesB0vqJwJau36IYs/0IlrhOXX
g1dB73TYKYWMD0QBm9jVWz9D4OJuYtxbNHeHu1lPm2IPcISVPj+NaPdFfbEgVjQH
9xqVQUozKexZpdx8YpuVkyR7v4CusNG8W0zp6pRPSQKecoUh9oYrDbk/HqyMYzX7
cXl1dR5M5rLBLtHvqgRE2eiXH6oN6TDZltgP87woCMZBljBF6UKSvZ2f3lkHpd0=
=mpUx
-----END PGP SIGNATURE-----

Stephen Hansen, Jul 11, 2010
9. ### Alf P. Steinbach /UsenetGuest

* 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>

Alf P. Steinbach /Usenet, Jul 11, 2010
10. ### Paul RubinGuest

rantingrick <> 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.

Paul Rubin, Jul 11, 2010
11. ### Stephen HansenGuest

On 7/11/10 12:30 AM, Alf P. Steinbach /Usenet wrote:
> * 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.

I'm aware of the "f" vs "v" vs "ph" thing, and the complexity of it
between languages and between the spoken verses written nature of
language. And for most instances, I'd just idly note, hey-- "My name is
Stephen" and leave it at that -- but this is not the first time with
I've run into it with this person, and neither is it the first time I've
responded to him and politely corrected him.

That, and I have seen absolutely no reason to think this person speaks
anything but standard American English. He has, for example, gone so far
as to create a rant which declared quite vocally that everyone should
adopt English, destroy Unicode and the usage of any other language, and
that anyone who didn't follow through with this was ultimately hurting
humanity. That any programmer which cow-towed towards this evil empire
of Unicodeness was just embracing separatism and decisiveness.

When this guy on more then one occasion chooses to articulate my name
improperly, I take it as an underhanded act with no purpose but to
belittle my point of view.

So yes. The first time, its a natural mistake, and I hold no hard
feelings. I regularly deal with people who misspell my name and
mispronounce my name. A polite correction invariably solves the problem,
and we are all happy.

But if one then makes the mistake again-- and in an entirely different
way (Stefan vs Steven) then they were politely corrected before-- its no
longer an issue of linguistic confusion at that point. At that point, I
have to assume he's doing it on purpose, and for the sole purpose of
being disrespectful and disparaging.

--

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)

iQEcBAEBAgAGBQJMOXiIAAoJEKcbwptVWx/lLaEH/iqhwkyU1AWaYYyZcxBt++36
TF86kw+ZFLk+c0vSDz/mTXH0l0eHAvMi95D9skiYa5GQqPJNI11HJInXekgaguux
8FNSUmUtGctZloX/dWSiON/fTMe/bGgL/L+YnWtLR1i+6+6TojcMJLdqong+bdY4
Dp2bBhHMaJuT/7UgGejC120aBtENvwnq3HT6Ns44XlXFVDlOTMFBCiPbxztvIhAp
lgVIovSUY7j8cwd2e99XL4zh2GtcsZJpYLt+4hvXLjnWgYDa4YJgfQ8MfplkhahX
cUt+kKWwDlOvpqmAr04rThv72c9aIReIYCMgXoNpm0CpST5xS11HqTVP2Nj53bM=
=AGFV
-----END PGP SIGNATURE-----

Stephen Hansen, Jul 11, 2010
12. ### rantingrickGuest

On Jul 11, 2:19 am, Stephen Hansen <me+list/> wrote:

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

I can't believe i actually have to prove to you that creating a tuple
and then testing for bool-inity takes more time than just the bool
test, but here goes *another* Sunday school lesson...

>>> s1 = "if (a, b) != (None, None):\n pass"
>>> t1 = timeit.Timer(s1, 'a=1;b=1')
>>> min(t1.repeat())

0.23950232000015603
>>> s2 = "if a is not None and b is not None:\n pass"
>>> t2 = timeit.Timer(s2, 'a=1;b=1')
>>> min(t2.repeat())

0.14334155999995346

> 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.

yea, been there done that.

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

obviously i sounded out your name in my head. It is getting pretty
late here after all so give me break for crying out loud.

> 1 is something.

Yes, but not necessarily a "True" something!

> 0 is nothing.

Yes, but not necessarily a "False" nothing!

What is a True "something" and what is a False "nothing" Stephen? Put
that one up where it belongs with the chicken and the egg where it
belongs -- next to the toilet with Hustler and Time.

> 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

haha, i love how you denied the fact that you used ad hominem attacks
and then directly after that tried to makes excuses for the very
behavior you denied. Clinton made a career out this very same story
telling. Nice work Bill Jr. *wink*

> 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.

No because i provide a very good reason --specifically in the case of
a conditional bool-ing-- that integers bool-ing to True/False can be
disastrous. And not only did i provide one reason, i provided two. The
second being that 1/0 as compared to True/False is misleading in it's
programming styles.

rantingrick, Jul 11, 2010
13. ### rantingrickGuest

On Jul 11, 2:39 am, Paul Rubin <> wrote:
> rantingrick <> 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:

<snip code>

Hmm, thanks for offering a solution but since functions call's induce
so much overhead and you use the len function in each condition i
believe the code would run much slower. How much slower, i don't know?
Maybe i'll run the test later. I need to come up with some good test
cases. Of course i'll want to maximize my side of the argument by
producing the most efficient code that really makes your look
slow. ;-)

rantingrick, Jul 11, 2010
14. ### bart.cGuest

"rantingrick" <> wrote in message
news:...
> 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

Or perhaps: if len(a):
...

> 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.

> choiceIdx1 = None
> choiceIdx2 = None
> if array[0] meets condition this condition:
> choiceIdx1 = 0
> for i in range(len(array)):
> if array meets this condition:
> choiceIdx2 = i
> break
> if choiceIdx1 and not choiceIdx2:

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

You can also blame the 0-based indexing in Python.

I'm not sure what would be the more fundamental change: changing over to
1-based indexing, or for 0 to be True (probably the opposite meaning to
every other language).

> 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 meets this condition:
> choiceIdx2 = (i,)
> break
> if choiceIdx1 and not choiceIdx2:

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

So, you're simply trying to signal whether a value is in the range 0 or
more, or not? That doesn't sound difficult: start with -1, then test whether
it's >=0.

But you're trying a boolean test where you expect None=False, and 0,1,2, etc
= True. While this would save typing in the condition, you're introducing
extraneous stuff elsewhere which makes it harder to read, such as (i,) just
to store an index.

--
Bartc

bart.c, Jul 11, 2010
15. ### Michael TorrieGuest

On 07/11/2010 12:50 AM, rantingrick wrote:
> Ah yes, when nothing else seems to work fall back to you default
> programming... FUD and ad hominem attacks

Please stop calling things what they are not. Stephen's post was not an
ad hominem attack, nor was it FUD. Someone who is countering your
premise and position (IE disagrees with you) is not automatically

Kudos to Stephen for replying in such a reasonable and even logical
fashion to your post. Would that you would reply to his posts in a
similar fashion, rather than leveling silly false accusations of "FUD

Michael Torrie, Jul 11, 2010
16. ### Mark DickinsonGuest

On Jul 11, 6:38 am, 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!

Okay. What fix do you propose? Would your fix maintain the identity
"0 == False"? For bonus points, explain how you'd deal with any
backwards compatibility problems that your fix introduces.

Have you considered forking Python? That may be the way forward here.

--
Mark

Mark Dickinson, Jul 11, 2010
17. ### rantingrickGuest

On Jul 11, 1:19 pm, Mark Dickinson <> wrote:

> Okay.  What fix do you propose?  Would your fix maintain the identity
> "0 == False"?

No because all integers should bool True. An integer is a value that
IS NOT empty and IS NOT None. Therefore the only logical way to handle
integer bool-ing is to say they are all True.

> For bonus points, explain how you'd deal with any
> backwards compatibility problems that your fix introduces.

We would't deal with backwards compatibility as this notion of bool(1)
== True and bool(0) == False if backwards way of thinking. Sure it
saves a few keystrokes but in the end only serves to obfuscate the
code and promote bad programming styles. WE SHOULD NEVER BE USING 1 IN
PLACE OF True AND 0 IN PLACE OF False!

> Have you considered forking Python?  That may be the way forward here.

I have considered this many times in the past and continue to
consider it even today. I believe the Python language to be the best
high level language ever created up to this point. I also believe GvR
to be a true genius who has forged the path of all 21st century high
level languages. However, like all new inventions eventually the
bright shiny paint job starts to oxidize and expose the rotten and
rusting core that has been slowly disintegrating behind the scenes all
along.

GvR stood on the shoulders of giants to reach the plateau of elegant
bliss that we know today as Python programming. As we all know
perfection will never be achieved, only lusted after forever and ever.
A perpetual game of cat and mouse. So maybe it is now time for the
next genius (Rick?) to stand on Guido's shoulders and reach the next

Maybe it was fate that CPython 3000 would disturb so many folks as to
create a question in their minds... A splinter lodged deep within the
mind constantly tickling new never before thoughts to form... "Is
Python all it can be?". A lustful yearning to fix the warts that have
been ignored for far too long and were scarified at the alter of the
simplistic development cycle.

But i think we are now at a crossroads people. We must forge the new
path and resist the temptation to circle around the familiar roads
endlessly. Heck *maybe* Guido himself is the architect of this change?
Maybe he *purposely* sowed discontent in an effort to ignite (or
reignite?) a passion for change within this community...?

The black monolith is before us. We have reached a crossroads. In the
balance hangs the future of high level programming languages. Will we
understand what the portal is and take the leap of faith forward, or
just bang some bones around like toddlers for another 10,000 years?
Only time will tell...? Only time will tell...?

rantingrick, Jul 12, 2010
18. ### geremy condraGuest

On Sun, Jul 11, 2010 at 7:22 PM, rantingrick <> wrote:
> On Jul 11, 1:19 pm, Mark Dickinson <> wrote:
>
>> Okay.  What fix do you propose?  Would your fix maintain the identity
>> "0 == False"?

>
> No because all integers should bool True. An integer is a value that
> IS NOT empty and IS NOT None. Therefore the only logical way to handle
> integer bool-ing is to say they are all True.
>
>> For bonus points, explain how you'd deal with any
>> backwards compatibility problems that your fix introduces.

>
> We would't deal with backwards compatibility as this notion of bool(1)
> == True and bool(0) == False if backwards way of thinking. Sure it
> saves a few keystrokes but in the end only serves to obfuscate the
> code and promote bad programming styles. WE SHOULD NEVER BE USING 1 IN
> PLACE OF True AND 0 IN PLACE OF False!
>
>> Have you considered forking Python?  That may be the way forward here.

>
>  I have considered this many times in the past and continue to
> consider it even today. I believe the Python language to be the best
> high level language ever created up to this point. I also believe GvR
> to be a true genius who has forged the path of all 21st century high
> level languages. However, like all new inventions eventually the
> bright shiny paint job starts to oxidize and expose the rotten and
> rusting core that has been slowly disintegrating behind the scenes all
> along.
>
>  GvR stood on the shoulders of giants to reach the plateau of elegant
> bliss that we know today as Python programming. As we all know
> perfection will never be achieved, only lusted after forever and ever.
> A perpetual game of cat and mouse. So maybe it is now time for the
> next genius (Rick?) to stand on Guido's shoulders and reach the next
> "cookie-jar-of-programming-enlightenment" one shelf higher than
>
>  Maybe it was fate that CPython 3000 would disturb so many folks as to
> create a question in their minds... A splinter lodged deep within the
> mind constantly tickling new never before thoughts to form... "Is
> Python all it can be?". A lustful yearning to fix the warts that have
> been ignored for far too long and were scarified at the alter of the
> simplistic development cycle.
>
>  But i think we are now at a crossroads people. We must forge the new
> path and resist the temptation to circle around the familiar roads
> endlessly. Heck *maybe* Guido himself is the architect of this change?
> Maybe he *purposely* sowed discontent in an effort to ignite (or
> reignite?) a passion for change within this community...?
>
> The black monolith is before us. We have reached a crossroads. In the
> balance hangs the future of high level programming languages. Will we
> understand what the portal is and take the leap of faith forward, or
> just bang some bones around like toddlers for another 10,000 years?
> Only time will tell...? Only time will tell...?

I literally laughed out loud as I read this. Go write some code, might
help connect you back to reality.

Geremy Condra

geremy condra, Jul 12, 2010
19. ### Steven D'ApranoGuest

On Sat, 10 Jul 2010 23:50:05 -0700, rantingrick wrote:

> You do realize that
> Python must build a tuple for ever conditional that uses this semantic?
> 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.

No, premature optimization is bad coding.

Building a tuple is extremely fast:

\$ python -m timeit "x = ()"
1000000 loops, best of 3: 0.316 usec per loop
\$ python -m timeit "x = False"
1000000 loops, best of 3: 0.36 usec per loop

Testing is fast too:

\$ python -m timeit "x = (); 1 if x else 2"
1000000 loops, best of 3: 0.663 usec per loop
\$ python -m timeit "x = False; 1 if x else 2"
1000000 loops, best of 3: 0.969 usec per loop

You've been around here long enough that you should know better. Stop
wasting your time, and ours, ranting over the enormous cost of things
that aren't costly at all. Come back when you have profiled your code and
can prove that the cost of building empty tuples is an actual bottleneck.

--
Steven

Steven D'Aprano, Jul 12, 2010
20. ### Mark LawrenceGuest

On 12/07/2010 01:02, Steven D'Aprano wrote:
> On Sat, 10 Jul 2010 23:50:05 -0700, rantingrick wrote:
>
>> You do realize that
>> Python must build a tuple for ever conditional that uses this semantic?
>> 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.

>
> No, premature optimization is bad coding.
>
> Building a tuple is extremely fast:
>
> \$ python -m timeit "x = ()"
> 1000000 loops, best of 3: 0.316 usec per loop
> \$ python -m timeit "x = False"
> 1000000 loops, best of 3: 0.36 usec per loop
>
>
> Testing is fast too:
>
> \$ python -m timeit "x = (); 1 if x else 2"
> 1000000 loops, best of 3: 0.663 usec per loop
> \$ python -m timeit "x = False; 1 if x else 2"
> 1000000 loops, best of 3: 0.969 usec per loop
>
>
> You've been around here long enough that you should know better. Stop
> wasting your time, and ours, ranting over the enormous cost of things
> that aren't costly at all. Come back when you have profiled your code and
> can prove that the cost of building empty tuples is an actual bottleneck.
>

+1

Kindest regards.

Mark Lawrence

Mark Lawrence, Jul 12, 2010