Python Forum

Full Version: boolean conditions
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
One thing that drives me nuts while reading python code is when people do this
if condition == False:
or
if len(condition) == 0:
when you can do
if not condition: 
PEP 8 even says "Don't compare boolean values to True or False using ==" :)
micseydel Wrote:Don't compare boolean values to True or False using ==
But it means that you can write
if condition is False
The semantics is slightly different from
if not condition
One can reasonably argue that good python code should not rely on such slight differences.
I stick with

if condition:
    pass

if not condition:
    pass
I have some C knowledge ( almost forgot it all already ) but I did the above when I was learning the Python basics even before seen how it is in Python. It just feels natural.
Here is a case where you need something different
def explain_python_value(value):
    if value is False:
        print('This is the boolean constant meaning "false".')
    elif value is None:
        print('The None object is often used to indicate an absence of value.')
    elif value == []:
        print("It's the empty list!")
    else:
        print('I have not yet been taught what this object is...')
In c, an rvalue is not necessarily a boolean, since boolean True equates to 1, and False equates to 0.
This is important when dealing with mixed C and assembler, because a 'short' (8 bit) 4 = 0000 0100, and if passed to the assembler
will be construed as False if used in the context of a boolean. You can use what C calls 'integral promotions' to create a boolean True from the 4 by assuring that bit zero is set to one.

assume variable z = 4 then z = ! ! z would become 0000 0001 which is now boolean True. and if it started as 0 would remain so, and would satisfy boolean False.

Been a while since I thought C or assembler so hope this makes sense.
(Nov-30-2018, 10:11 AM)Gribouillis Wrote: [ -> ]Here is a case where you need something different
def explain_python_value(value):
    if value is False:
        print('This is the boolean constant meaning "false".')
    elif value is None:
        print('The None object is often used to indicate an absence of value.')
    elif value == []:
        print("It's the empty list!")
    else:
        print('I have not yet been taught what this object is...')
well in that case yes, its required. More often than not though, they are not comparing an empty container, None, or a boolean value.
I have used if go is True:. I have a method that automatically bears pieces off the board in Backgammon. The go variable is whether or not your turn continues, and is initialized to True at the start of the method. If a roll is used to bear off a piece, go is set to the list of remaining rolls. That way, if you have any rolls left after all possible automatic bearings, your turn continues. If not, it ends. However, there is a warning to the player if nothing was automatically moved. In that case I want to distinguish between go never having been changed after a successful move (is True) and go having been changed but still evaluating as True (a non-empty list).

I also use it in a case where the user can specify a particular type of option. The default for all options is True. But anything they specify will also evaluate as True. So I use it to distinguish the default from a specified value.
I think in that case, I'd just return a tuple of two values. The first would always be True/False, and the second would be a list of available rolls/moves. Used like: turn_continues, remaining_rolls = advance_board_state().

But if it works, don't break it :p
(Nov-30-2018, 04:17 PM)nilamo Wrote: [ -> ]I think in that case, I'd just return a tuple of two values.

I suppose I could do that. I did it the way I did because there is a type of method in my framework that is required to return a single true/false value as to whether or not the turn continues. While the method in question is called by a method of that type, it isn't a method of that type itself. However, the go variable has all the information that is needed. Why create another variable just to avoid a particular kind of condition? The problem with if condition == True: is that it's generally redundant. It works fine without the == True. But that's generally. In this specific case it's not redundant. You would have different functionality if you remove the is True.
Pages: 1 2