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

R

rantingrick

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

Instead of this

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

Stephen Hansen

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
F+Wjdc/QUdjAlOIN004aEFg0YS47qdNeXtgLbW/QLwTsDeaDdsDJMWYte5Qm8YmX
U6Rl8J6dMWXk8sZdtjFJGCijFX3gDOjLgjzJ2GVU/iG5IC1lnqH+Zy+zVSmoK28=
=mDNt
-----END PGP SIGNATURE-----
 
R

rantingrick

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
 
S

Stephen Hansen

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

rantingrick

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.


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

Ian Kelly

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.

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

Ian Kelly

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

Stephen Hansen

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

Alf P. Steinbach /Usenet

* Stephen Hansen, on 11.07.2010 09:19:
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
 
P

Paul Rubin

rantingrick said:
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.
 
S

Stephen Hansen

* Stephen Hansen, on 11.07.2010 09:19:

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

rantingrick

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...
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
intention. Which renders code less readable, and supports bad
programming styles.
 
R

rantingrick

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. ;-)
 
B

bart.c

rantingrick said:
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

Instead of this

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

Michael Torrie

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
attacking your character or some characteristic of your person.

http://en.wikipedia.org/wiki/Ad_hominem#Common_misconceptions_about_ad_hominem

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
and ad hominem attacks."
 
M

Mark Dickinson

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

rantingrick

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
Guido's cookies where found.

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

geremy condra

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.


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!


 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
Guido's cookies where found.

 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
 
S

Steven D'Aprano

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.

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

Mark Lawrence

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,832
Latest member
GlennSmall

Latest Threads

Top