True inconsistency in Python

Discussion in 'Python' started by Scott Chapman, Nov 13, 2003.

  1. There seems to be an inconsistency here:

    Python 2.3.2 (#1, Oct 3 2003, 19:04:58)
    [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
    >>> 1 == True

    True
    >>> 3 == True

    False
    >>> if 1: print "true"

    ....
    true
    >>> if 3: print "true"

    ....
    true

    >>> 0 == False

    True
    >>> -1 == False

    False
    >>> -1 == True

    False
    >>> if -1: print "true"

    ....
    true
    >>> if -2: print "true"

    ....
    true

    >>> if None:

    .... print "hello"
    ....
    >>> x = None
    >>> x == None

    True
    >>> x == True

    False
    >>> x == False

    False
    >>> x <> True

    True
    >>> x <> False

    True
    >>> None == True

    False
    >>> None == False

    False


    Historically Python has allowed <> 0 to equal true in evaluations. Now
    <> 0 still evaluates to true in evaluations. However it doesn't equal
    True. They are not interchangable. (Same with empty lists, etc.)
    Assuming the old behavior is desired, programmers need to be careful
    not to compare a variable with True as in:

    if var == True: # only works if var is 1
    blah

    ' Must use:

    if var: # works if var is not 0
    blah

    Is this inconsistency going to be resolved in the future?

    How? (Will <>0 == True or will <>0 <> true or will it be resolved some
    other way that I'm too opaque to see? :)

    It seems that maybe Python should throw a warning (perhaps if a flag is
    set) any time it bumps into code comparing a variable to True or False.
    It's pretty subtle and would easily throw a newbie.

    Of course, according to the above logic, if 1 == true and 2 == true,
    then 1 == 2! Thankfully this doesn't work in Python. Python is magic.
    I love the magic but it creates some interesting inconsistencies.

    Scott
    Scott Chapman, Nov 13, 2003
    #1
    1. Advertising

  2. Scott Chapman wrote:

    > Historically Python has allowed <> 0 to equal true in evaluations.
    > Now
    > <> 0 still evaluates to true in evaluations. However it doesn't equal
    > True. They are not interchangable. (Same with empty lists, etc.)


    That's because the proper way to test for truth does not use the True
    value at all. It is this:

    if x:
    ...

    not this:

    if x == True:
    ...

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ Life is a predicament which precedes death.
    \__/ Henry James
    Erik Max Francis, Nov 13, 2003
    #2
    1. Advertising

  3. Scott Chapman

    Ben Finney Guest

    On Wed, 12 Nov 2003 19:42:27 -0800, Scott Chapman wrote:
    > There seems to be an inconsistency here:


    Yes. The inconsistency is in expecting all Boolean truths to be the
    same value.

    The object True will evaluate as a Boolean truth. The object False will
    not evaluate as a Boolean truth. This doesn't mean that there are no
    other values that will or won't evaluate as Boolean truth.

    You many want to read the PEP that led to the creation of the 'bool'
    type (and True and False objects):

    <http://www.python.org/peps/pep-0285.html>

    In short: Testing the Boolean truth of an expression is done with 'if',
    not with value-comparison operators.

    --
    \ "bash awk grep perl sed, df du, du-du du-du, vi troff su fsck |
    `\ rm * halt LART LART LART!" -- The Swedish BOFH, |
    _o__) alt.sysadmin.recovery |
    Ben Finney <http://bignose.squidly.org/>
    Ben Finney, Nov 13, 2003
    #3
  4. Scott Chapman

    David C. Fox Guest

    Scott Chapman wrote:

    >
    > if var == True: # only works if var is 1
    > blah
    >
    > ' Must use:
    >
    > if var: # works if var is not 0
    > blah


    Just because something isn't True doesn't mean it isn't true.

    David
    David C. Fox, Nov 13, 2003
    #4
  5. Scott Chapman

    Ben Finney Guest

    On Thu, 13 Nov 2003 06:26:09 GMT, Ron Adam wrote:
    > The only thing that surprises me in all of this is the "if var:"
    > evaluating to true for numbers other than 1. That's new to me, I
    > would have expected an exception in that case.


    Python has only recently gained a Boolean type ('bool').

    <http://www.python.org/peps/pep-0285.html>

    Before that, Boolean logic was done with integer values. Zero equated
    to Boolean false, non-zero equated to Boolean true; and the default
    Boolean true value was simply the integer 1.

    This conflation of types is confusing, and (like many other languages)
    Python has now "grown a Boolean type" to distinguish integer 0 and 1
    from Boolean False and True. However, the previous behaviour is still
    supported -- for how long, I don't know.

    --
    \ "Injustice is relatively easy to bear; what stings is justice." |
    `\ -- Henry L. Mencken |
    _o__) |
    Ben Finney <http://bignose.squidly.org/>
    Ben Finney, Nov 13, 2003
    #5
  6. Scott Chapman

    Ron Adam Guest

    On Wed, 12 Nov 2003 19:42:27 -0800, Scott Chapman
    <> wrote:

    >
    >Historically Python has allowed <> 0 to equal true in evaluations. Now
    ><> 0 still evaluates to true in evaluations. However it doesn't equal
    >True.



    >>>a = (2 != 0)
    >>>a == True

    True

    Seems to work for me. Am I missing something?

    The only thing that surprises me in all of this is the "if var:"
    evaluating to true for numbers other than 1. That's new to me, I
    would have expected an exception in that case. But it still makes
    since if I look at it as a shortcut for "if (var != 0):". This
    only proves I'm still relatively new to Python I think.

    _Ron Adam
    Ron Adam, Nov 13, 2003
    #6
  7. Scott Chapman

    Ron Adam Guest

    On 13 Nov 2003 17:08:13 +1050, Ben Finney
    <> wrote:

    >On Thu, 13 Nov 2003 06:26:09 GMT, Ron Adam wrote:
    >> The only thing that surprises me in all of this is the "if var:"
    >> evaluating to true for numbers other than 1. That's new to me, I
    >> would have expected an exception in that case.

    >
    >Python has only recently gained a Boolean type ('bool').
    >
    > <http://www.python.org/peps/pep-0285.html>
    >
    >Before that, Boolean logic was done with integer values. Zero equated
    >to Boolean false, non-zero equated to Boolean true; and the default
    >Boolean true value was simply the integer 1.
    >
    >This conflation of types is confusing, and (like many other languages)
    >Python has now "grown a Boolean type" to distinguish integer 0 and 1
    >from Boolean False and True. However, the previous behaviour is still
    >supported -- for how long, I don't know.


    That's good to know. I've always explicitly defined my bool values as
    0 and 1 so it's never been a problem.

    Thanks for the PEP link, it was informative.

    _Ron Adam
    Ron Adam, Nov 13, 2003
    #7
  8. Ron Adam:
    > The only thing that surprises me in all of this is the
    > "if var:" evaluating to true for numbers other than 1.
    > That's new to me, I would have expected an
    > exception in that case. But it still makes since if I
    > look at it as a shortcut for "if (var != 0):". This only
    > proves I'm still relatively new to Python I think.


    It's handy, and natural in many real life situations, to treat any nonzero
    value as "true". For example:

    Do you have any money in your wallet?

    Do you have children?

    I could ask how much money or how many children you have, but if I just ask
    the yes-or-no question, you'll naturally answer "yes" for any nonzero value.

    Of course, if you have children, you won't have money, but that's a separate
    problem...

    -Mike
    Michael Geary, Nov 13, 2003
    #8
  9. Scott Chapman

    Borcis Guest

    Scott Chapman wrote:

    >
    > if var == True: # only works if var is 1
    > blah
    >
    > ' Must use:
    >
    > if var: # works if var is not 0
    > blah


    there's the equivalent, and more explicit :

    if bool(var)==True : blah
    Borcis, Nov 13, 2003
    #9
  10. On Wed, 12 Nov 2003 21:21:03 -0800, Erik Max Francis <>
    wrote:

    >Scott Chapman wrote:
    >
    >> Historically Python has allowed <> 0 to equal true in evaluations.
    >> Now
    >> <> 0 still evaluates to true in evaluations. However it doesn't equal
    >> True. They are not interchangable. (Same with empty lists, etc.)

    >
    >That's because the proper way to test for truth does not use the True
    >value at all. It is this:
    >
    > if x:
    > ...
    >
    >not this:
    >
    > if x == True:
    > ...

    Sort of like (stretchy) saying that if these are both True:
    "a snake is green"
    "a pearl is white"
    that they are the same as each other.
    They are both true, yet unrelated. You can say:
    if "a snake is green": print 1
    if "a pearl is white": print 2
    and the prints would happen, but if you said
    if "a snake is green" == "a pearl is white": print 3
    the print would not happen.

    --dang
    Dang Griffith, Nov 13, 2003
    #10
  11. Borcis wrote:

    > Scott Chapman wrote:
    >
    >>
    >> if var == True: # only works if var is 1
    >> blah
    >>
    >> ' Must use:
    >>
    >> if var: # works if var is not 0
    >> blah

    >
    > there's the equivalent, and more explicit :
    >
    > if bool(var)==True : blah


    Why stop there? If adding one useless and redundant check is
    better, surely having more will be merrier and merrier...:

    if ( bool(var) == True) == True: doubleblah

    oh wait, we should add ANOTHER level of uselessness...:

    if (( bool(var) == True) == True) == True: tripleblah

    oh wait...


    "if var:" is the Pythonic way. You could argue that each
    level of "== True" makes it ``more explicit'', but I just
    consider them all equally silly in their utter redundancy.

    [[ we TOLD Guido people would start on this absurd path, when
    he added bool, True, and False, but he wouldn't listen...
    ]]


    Alex
    Alex Martelli, Nov 13, 2003
    #11
  12. Ben Finney wrote:
    ...
    > This conflation of types is confusing, and (like many other languages)
    > Python has now "grown a Boolean type" to distinguish integer 0 and 1
    > from Boolean False and True. However, the previous behaviour is still
    > supported -- for how long, I don't know.


    I've never heard of any plans (not even for the totally mythical
    "Python 3000") to remove or even deprecate Python's extremely useful
    and practical feature that:
    -- any value can be used as a true-or-false condition,
    -- zero numbers, empty containers, and user-coded objects defining
    __nonzero__ (or else __len__) and returning 0 are taken as false,
    -- all other values are taken as true.


    Alex
    Alex Martelli, Nov 13, 2003
    #12
  13. Ben Finney
    > You many want to read the PEP that led to the creation of the 'bool'
    > type (and True and False objects):


    .... or vise versa

    Emile van Sebille
    Emile van Sebille, Nov 13, 2003
    #13
  14. Scott Chapman wrote:
    ...
    > It seems that maybe Python should throw a warning (perhaps if a flag is
    > set) any time it bumps into code comparing a variable to True or False.


    It's a bit hard to do it just for variables, but doing it for _any_
    comparison would _almost_ be reasonable -- testing if something
    "== True" is hardly ever sensible. Unfortunately "a == b" CAN
    be perfectly sensible and either or both of the variables MIGHT
    just happen to be set to True.

    However, this looks to me like a good suggestion for PyChecker
    and the like, which should be able to catch and flag the actual
    explicit use or the constant True in code involving == or != ...


    Alex
    Alex Martelli, Nov 13, 2003
    #14
  15. Scott Chapman

    Gerrit Holl Guest

    Alex Martelli wrote:
    (about x vs. bool(x))
    > [[ we TOLD Guido people would start on this absurd path, when
    > he added bool, True, and False, but he wouldn't listen...
    > ]]


    What do double square brackets mean?

    (btw, I _do_ use bool ocasionally: I implemented an anytrue() function
    using sum([bool(i) for i in L]), is this wrong?)

    Gerrit.

    --
    128. If a man take a woman to wife, but have no intercourse with her,
    this woman is no wife to him.
    -- 1780 BC, Hammurabi, Code of Law
    --
    Asperger Syndroom - een persoonlijke benadering:
    http://people.nl.linux.org/~gerrit/
    Kom in verzet tegen dit kabinet:
    http://www.sp.nl/
    Gerrit Holl, Nov 13, 2003
    #15
  16. Borcis wrote:

    > there's the equivalent, and more explicit :
    >
    > if bool(var)==True : blah


    The explicitness here does not gain you anything. In a truth context,
    x, bool(x), and bool(x) == True are all precisely identical. There is
    absolutely no value gained by writing bool(x) == True instead of just x.

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \
    \__/ The golden rule is that there are no golden rules. -- George
    Bernard Shaw
    Erik Max Francis, Nov 13, 2003
    #16
  17. Scott Chapman

    Ron Adam Guest

    On Thu, 13 Nov 2003 00:19:31 -0800, "Michael Geary"
    <> wrote:

    >Ron Adam:
    >> The only thing that surprises me in all of this is the
    >> "if var:" evaluating to true for numbers other than 1.
    >> That's new to me, I would have expected an
    >> exception in that case. But it still makes since if I
    >> look at it as a shortcut for "if (var != 0):". This only
    >> proves I'm still relatively new to Python I think.

    >
    >It's handy, and natural in many real life situations, to treat any nonzero
    >value as "true". For example:
    >
    >Do you have any money in your wallet?
    >
    >Do you have children?
    >
    >I could ask how much money or how many children you have, but if I just ask
    >the yes-or-no question, you'll naturally answer "yes" for any nonzero value.
    >
    >Of course, if you have children, you won't have money, but that's a separate
    >problem...
    >
    >-Mike
    >


    That makes since, Thanks for clarifying this.

    I learned boolean logic as part of a computer tech degree back in
    early 80's. Binary logic circuits use only 0 and 1. So it's the way
    I think when dealing with bool type.

    _Ron Adam
    Ron Adam, Nov 13, 2003
    #17
  18. Gerrit Holl <> wrote in message news:<>...
    >
    > (btw, I _do_ use bool ocasionally: I implemented an anytrue() function
    > using sum([bool(i) for i in L]), is this wrong?)
    >
    > Gerrit.
    >
    > --
    > 128. If a man take a woman to wife, but have no intercourse with her,
    > this woman is no wife to him.
    > -- 1780 BC, Hammurabi, Code of Law


    It does not shortcut, i.e. it creates the full list. For the rest, it
    is a matter of personal opinion if this idea is considered cool or
    an abuse of sum. I personally, will propend for the latter, but since
    we don't have yet an anytrue function in the library, for the moment it
    can be tolered). Just my 0.02 E.

    Michele
    Michele Simionato, Nov 14, 2003
    #18
  19. Scott Chapman

    Terry Reedy Guest

    "Ben Finney" <> wrote
    in message news:...
    > This conflation of types is confusing,


    but very useful

    >and (like many other languages)
    > Python has now "grown a Boolean type" to distinguish integer 0 and 1
    > from Boolean False and True. However, the previous behaviour is

    still
    > supported -- for how long, I don't know.


    When bool was introduced, Guido promised that is would always remain a
    subtype of int. Crippling usefulness in the name of mathematical
    purity is not on the table.

    Terry J. Reedy
    Terry Reedy, Nov 14, 2003
    #19
  20. Scott Chapman

    Terry Reedy Guest

    "Scott Chapman" <> wrote in message
    news:...
    > There seems to be an inconsistency here:


    In regard to logic, the current Python implementation acts just as
    specified in the manaul, which is written as intended. This is the
    only consistency relevant to Python.

    In math, an inconsistent set of premises is one from which one can
    derive both true and false. Python as delivered has no such
    inconsistency in that sense either. bool(object) is either True or
    False for every Python object except possibly for instances of a user
    class with the appropriate special method mangled either by accident
    or perverse intention.

    In static math, x = x+1 is read as x == x+1, which is usually false.
    But programming is not mathematics.

    If you merely meant "Python is not consistent with my expectations"
    then I suppose you are right. If that really bothers you, I suspect
    you know the realistic remedy ;-).

    Terry J. Reedy
    Terry Reedy, Nov 14, 2003
    #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:
    648
    Chris Theis
    Jun 18, 2004
  2. Chip
    Replies:
    6
    Views:
    2,614
    E. Robert Tisdale
    Jan 8, 2005
  3. Jimmy Retzlaff

    RE: True inconsistency in Python

    Jimmy Retzlaff, Nov 17, 2003, in forum: Python
    Replies:
    2
    Views:
    423
    Terry Reedy
    Nov 18, 2003
  4. Andy Leszczynski
    Replies:
    4
    Views:
    314
    Erik Max Francis
    Oct 13, 2005
  5. bdb112
    Replies:
    45
    Views:
    1,311
    jazbees
    Apr 29, 2009
Loading...

Share This Page