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

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

  1. rantingrick

    rantingrick Guest

    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!
     
    rantingrick, Jul 11, 2010
    #1
    1. Advertising

  2. 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
    F+Wjdc/QUdjAlOIN004aEFg0YS47qdNeXtgLbW/QLwTsDeaDdsDJMWYte5Qm8YmX
    U6Rl8J6dMWXk8sZdtjFJGCijFX3gDOjLgjzJ2GVU/iG5IC1lnqH+Zy+zVSmoK28=
    =mDNt
    -----END PGP SIGNATURE-----
     
    Stephen Hansen, Jul 11, 2010
    #2
    1. Advertising

  3. rantingrick

    rantingrick Guest

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

    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
     
    rantingrick, Jul 11, 2010
    #3
  4. 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
    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-----
     
    Stephen Hansen, Jul 11, 2010
    #4
  5. rantingrick

    rantingrick Guest

    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
    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 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.
     
    rantingrick, Jul 11, 2010
    #5
  6. rantingrick

    Ian Kelly Guest

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

    Ian Kelly Guest

    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
    #7
  8. 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
    > 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/


    -----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
    #8
  9. * 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
    #9
  10. rantingrick

    Paul Rubin Guest

    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
    #10
  11. 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
    #11
  12. rantingrick

    rantingrick Guest

    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
    intention. Which renders code less readable, and supports bad
    programming styles.
     
    rantingrick, Jul 11, 2010
    #12
  13. rantingrick

    rantingrick Guest

    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
    #13
  14. rantingrick

    bart.c Guest

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

    --
    Bartc
     
    bart.c, Jul 11, 2010
    #14
  15. 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
    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."
     
    Michael Torrie, Jul 11, 2010
    #15
  16. 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
    #16
  17. rantingrick

    rantingrick Guest

    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
    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...?
     
    rantingrick, Jul 12, 2010
    #17
  18. 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
    > 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
     
    geremy condra, Jul 12, 2010
    #18
  19. 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?
    > 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.



    --
    Steven
     
    Steven D'Aprano, Jul 12, 2010
    #19
  20. 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?
    >> 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.
    >


    +1

    Kindest regards.

    Mark Lawrence
     
    Mark Lawrence, Jul 12, 2010
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Siemel Naran

    Does true ^ true return false?

    Siemel Naran, Jun 17, 2004, in forum: C++
    Replies:
    19
    Views:
    669
    Chris Theis
    Jun 18, 2004
  2. Pierre Quentel

    "0 in [True,False]" returns True

    Pierre Quentel, Dec 12, 2005, in forum: Python
    Replies:
    59
    Views:
    1,034
    Grant Edwards
    Dec 16, 2005
  3. André
    Replies:
    3
    Views:
    1,596
  4. bdb112
    Replies:
    45
    Views:
    1,348
    jazbees
    Apr 29, 2009
  5. Shea Martin

    false or true == true .... WTF?

    Shea Martin, Apr 5, 2007, in forum: Ruby
    Replies:
    4
    Views:
    108
    Bertram Scharpf
    Apr 5, 2007
Loading...

Share This Page