I cannot add the integer number 1 to an existing set. In an interactive shell, this is what I am doing:
>>> st = {'a', True, 'Vanilla'}
>>> st
{'a', True, 'Vanilla'}
>>> st.add(1)
>>> st
{'a', True, 'Vanilla'} # Here's the problem; there's no 1, but anything else works
>>> st.add(2)
>>> st
{'a', True, 'Vanilla', 2}
This question was posted two months ago, but I believe it was misunderstood.
I am using Python 3.2.3.
>>> 1 == True
True
I believe your problem is that 1 and True are the same value, so 1 is "already in the set".
>>> st
{'a', True, 'Vanilla'}
>>> 1 in st
True
In mathematical operations True is itself treated as 1:
>>> 5 + True
6
>>> True * 2
2
>>> 3. / (True + True)
1.5
Though True is a bool and 1 is an int:
>>> type(True)
<class 'bool'>
>>> type(1)
<class 'int'>
Because 1 in st returns True, I think you shouldn't have any problems with it. It is a very strange result though. If you're interested in further reading, #Lattyware points to PEP 285 which explains this issue in depth.
I believe, though I'm not certain, that because hash(1) == hash(True) and also 1 == True that they are considered the same elements by the set. I don't believe that should be the case, as 1 is True is False, but I believe it explains why you can't add it.
1 is equivalent to True as 1 == True returns true. As a result the insertion of 1 is rejected as a set cannot have duplicates.
Here are some link if anyone is interested in further study.
Is it Pythonic to use bools as ints?
https://stackoverflow.com/a/2764099/1355722
We have to use a list if you want to have items with the same hash.If you're absolutely sure your set needs to be able to contain both True and 1.0, I'm pretty sure you'll have to define your own custom class, probably as a thin wrapper around dict.
As in many languages, Python's set type is just a thin wrapper around dict where we're only interested in the keys.
Ex:
st = {'a', True, 'Vanilla'}
list_st = []
for i in st:
list_st.append(i)
list_st.append(1)
for i in list_st:
print(f'The hash of {i} is {hash(i)}')
produces
The hash of True is 1
The hash of Vanilla is -6149594130004184476
The hash of a is 8287428602346617974
The hash of 1 is 1
[Program finished]
Related
I was checking some of CPython's tests and in this file I saw a test case which was strange to me:
def test_math(self):
...
self.assertIsNot(+False, False)
At first I thought it is a typo and it should be self.assertIs(+False, False) but when I tried it on the Python console the result was False:
>>> +False is False
<stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
False
>>>
>>> id(False)
140078839501184
>>> id(+False)
140078839621760
Why does + make it a different object?
Comments suggest that +False is 0. So maybe the better question should be why is this?
Because a bool is a type of int:
>>> isinstance(False, int)
True
>>> False == 0
True
a bool is accepted by functions that take ints as inputs (including all the standard operators), and those functions will generally return ints:
>>> True + False
1
>>> True * 2
2
>>> True ** False
1
or sometimes floats:
>>> True / True
1.0
Specifically, putting + in front of a number is a "unary plus", the opposite of a "unary minus" which returns the negative of its operand:
>>> +True
1
>>> -True
-1
>>> +False
0
>>> -False
0
Although this bool/int behavior catches most people off guard the first time they find it, it allows for some useful shortcuts; for example, you can sum a bunch of bools to find the number of True values:
>>> sum([True, True, False, False, True])
3
>>> sum(s.startswith("a") for s in ("apple", "banana", "pear", "avocado"))
2
When you apply arithmetic operations to boolean values they are turned into int.
In [10]: type(+False)
Out[10]: int
In [11]: type(False)
Out[11]: bool
Let's say I have a list with different values, like this:
[1,2,3,'b', None, False, True, 7.0]
I want to iterate over it and check that every element is not in list of some forbidden values. For example, this list is [0,0.0].
When I check if False in [0,0.0] I get True. I understand that python casts False to 0 here - but how I can avoid it and make this check right - that False value is not in [0,0.0]?
To tell the difference between False and 0 you may use is to compare them. False is a singleton value and always refers to the same object. To compare all the items in a list to make sure they are not False, try:
all(x is not False for x in a_list)
BTW, Python doesn't cast anything here: Booleans are a subclass of integers, and False is literally equal to 0, no conversion required.
You would want to use is instead of == when comparing.
y = 0
print y == False # True
print y is False # False
x = False
print x == False # True
print x is False # True
Found a weird corner case on differentiating between 0 and False today. If the initial list contains the numpy version of False (numpy.bool_(False)), the is comparisons don't work, because numpy.bool_(False) is not False.
These arise all the time in comparisons that use numpy types. For example:
>>> type(numpy.array(50)<0)
<class 'numpy.bool_'>
The easiest way would be to compare using the numpy.bool_ type: (np.array(50)<0) is (np.False_). But doing that requires a numpy dependency. The solution I came up with was to do a string comparison (working as of numpy 1.18.1):
str(numpy.bool_(False)) == str(False)
So when dealing with a list, a la #kindall it would be:
all(str(x) != str(False) for x in a_list)
Note that this test also has a problem with the string 'False'. To avoid that, you could exclude against cases where the string representation was equivalent to itself (this also dodges a numpy string array). Here's some test outputs:
>>> foo = False
>>> str(foo) != foo and str(foo) == str(False)
True
>>> foo = numpy.bool_(False)
>>> str(foo) != foo and str(foo) == str(False)
True
>>> foo = 0
>>> str(foo) != foo and str(foo) == str(False)
False
>>> foo = 'False'
>>> str(foo) != foo and str(foo) == str(False)
False
>>> foo = numpy.array('False')
>>> str(foo) != foo and str(foo) == str(False)
array(False)
I am not really an expert programmer, so there may be some limitations I've still missed, or a big reason not to do this, but it allowed me to differentiate 0 and False without needing to resort to a numpy dependency.
In my program encountered with this:
>>> True and True and (3 or True)
3
>>> True and True and ('asd' or True)
'asd'
while I expected to get some boolean value depending on the result in brackets. So if I try comparisons like these (0 or True) or ('' or True) python will return True, which is clear because 0 and '' equivalent to False in comparisons.
Why doesn't python return boolean value by converting 3 and 'asd' into True?
From https://docs.python.org/3/library/stdtypes.html:
Important exception: the Boolean operations or and and always return
one of their operands
The behavior can be most easily seen with:
>>> 3 and True
True
>>> True and 3
3
If you need to eliminate this behavior, wrap it in a bool:
>>> bool(True and 3)
True
See this question
As Reut Sharabani, answered, this behavior allows useful things like:
>>> my_list = []
>>> print (my_list or "no values")
I've come across a surprising situation when using numpy's arrays. The following code
(True==True)+(True==True)
returns 2, as one would expect. While
import numpy
Array=numpy.zeros((2,2),dtype=bool)
(Array[0][0]==Array[0][0])+(Array[1][0]==Array[1][0])
returns True. This leads to:
(Array[0][0]==Array[0][0])+(Array[1][0]==Array[1][0])-1
returning 0, while
(Array[0][0]==Array[0][0])-1+(Array[1][0]==Array[1][0])
returns 1, making the sum not commutative!
Is this intended? If so, why?
It would appear that numpy.bool_ behaves slightly differently to vanilla Python bool:
>>> int(True+True) == int(True) + int(True)
True
>>> int(numpy.bool_(1)+numpy.bool_(1)) == int(numpy.bool_(1)) + int(numpy.bool_(1))
False
This is because:
>>> True+True
2
>>> numpy.bool_(1)+numpy.bool_(1)
True
>>> int(numpy.bool_(1)+numpy.bool_(1))
1
Basically, the addition operation for numpy.bool_ is logical, rather than numerical; to get the same behaviour with bool:
>>> int(True and True)
1
This is fine if you only use it for truthiness, as intended, but if you try to use it in an integer context without being explicit about that, you end up surprised. As soon as you're explicit, expected behaviour is restored:
>>> int(numpy.bool_(1)) + int(numpy.bool_(1))
2
I think the problem is th autocasting.
in this case:
(Array[0][0]==Array[0][0])+(Array[1][0]==Array[1][0])-1
Python do:
(Array[0][0]==Array[0][0])+(Array[1][0]==Array[1][0]) = True
True -1 =cast= 1 -1 = 0
In the second case the cast is do it before:
(Array[0][0]==Array[0][0])-1+(Array[1][0]==Array[1][0])
True - 1 + True
(True - 1 =cast= 0)
0 + True =cast again= 0+ 1 = 1
So, it's not a bug. It's a autocasting in diferent parts.
I'm going through the LPTHW and I came across something I cannot understand. When will it ever be the case that you want your boolean and or or to return something other than the boolean? The LPTHW text states that all languages like python have this behavior. Would he mean interpreted vs. compiled languages or duck typed vs static typed languages?
I ran the following code:
>>> False and 1
False
>>> True and 1
1
>>> 1 and False
False
>>> 1 and True
True
>>> True and 121
121
>>> False or 1
1
>>> False or 112
112
>>> False or "Khadijah"
'Khadijah'
>>> True and 'Khadijah'
'Khadijah'
>>> False or 'b'
'b'
>>> b = (1, 2, "K")
>>> b
(1, 2, 'K')
>>> False or b
(1, 2, 'K')
>>>
Please help me understand whats going on here.
According to the documentation: http://docs.python.org/2/library/stdtypes.html
Operations and built-in functions that have a Boolean result always return 0 or False for false and 1 or True for true, unless otherwise stated. (Important exception: the Boolean operations or and and always return one of their operands.)
According to LPTHW: http://learnpythonthehardway.org/book/ex28.html
Why does "test" and "test" return "test" or 1 and 1 return 1 instead of True?
Python and many languages like it return one of the operands to their boolean expressions rather than just True or False. This means that if you did False and 1 you get the first operand (False) but if you do True and 1 your get the second (1). Play with this a bit.
I think you're somehow confused about what the docs says. Take a look at these two docs sections: Truth Value Testing and Boolean Operators. To quote the last paragraph on the fist section:
Operations and built-in functions that have a Boolean result always return 0 or False for false and 1 or True for true, unless otherwise stated. (Important exception: the Boolean operations or and and always return one of their operands.)
As you can see, you're right about operations and built-in functions but see the Important exception part, it is well stated that the Boolean operators will return one of their operands.
Now, what they can return depends hardly on the operator's short circuit logic. For or operator, it will return the first truthy value in the expression, since when it finds one, the whole expression is true. In case of every operand being falsey, or will return the last operand, meaning that it iterated over every one of them not being able to find a truthy one.
For and operator, if the expression is true, it will return the last operand, if the expression is false, it will return the first falsey operand. You can read more about Short Circuit Evaluation at the Wikipedia Page.
You have a lot of examples in your question, let's analyze some of them:
>>> False and 1 # return false (short circuited at first falsey value)
False
>>> True and 1 # return 1 (never short circuited and return the last truthy value)
1
>>> 1 and False # return false (short circuited at first falsey value, in this case the last operand)
False
>>> 1 and True # return True (never short circuited and return the last truthy value)
True
>>> True and 121 # return 121 (never short circuited and return the last truthy value)
121
>>> False or 1 # return 1 (since the first operand was falsey, or kept looking for a first truthy value which happened to be the last operator)
1
>>> False or 112 # return 112 for same reason as above
112
>>> False or "Khadijah" # return "Khadijah" for same reason as above
'Khadijah'
>>> True and 'Khadijah' # return "Khadijah" because same reason as second example
'Khadijah'
I think this should make a point. To help you further understand why this is useful, consider the following example:
You have a function that randomly generate names
import random
def generate_name():
return random.choice(['John', 'Carl', 'Tiffany'])
and you have a variable that you don't know if it has assigned a name yet so instead of doing:
if var is None:
var = generate_name()
You can do oneliner:
var = var or generate_name()
Since None is a falsey value, or will continue its search and evaluate second operand, this is, call the function ultimately returning the generated name. This is a very silly example, I have seen better usages (although not in Python) of this kind of style. I couldn't come out with a better example right now. You can also take a look at this questions, there are very useful answers on the topic: Does Python support short-circuiting?
Last but not least, this has nothing to do with static typed, duck typed, dynamic, interpreted, compiled, whatever language. It's just a language feature, one that might come handy and that is very common since almost every programming language I can think of provide this feature.
Hope this helps!
One would want and and or to evaluate to an operand (as opposed to always evaluating to True or False) in order to support idioms like the following:
def foo(self):
# currentfoo might be None, in which case return the default
return self.currentfoo or self.defaultfoo()
def foobar(self):
# foo() might return None, in which case return None
foo = self.foo()
return foo and foo.bar()
You can of course question the value of such idioms, especially if you aren't used to them. It's always possible to write equivalent code with an explicit if.
As a point against them, they leave some doubt whether the full range of falsey values is possible and intentionally accounted for, or just the one mentioned in the comment (with other falsey values not permitted). But then, this is true in general of code that uses the true-ness of a value that might be something other than True or False. It occasionally but rarely leads to misunderstandings.
This has to do with the way short circuit effect is implemented in Python.
With and (remember True and X = X), the result of the right expression is pushed into the stack, if it's false, it gets poped immediately, else the second expression is poped:
>>> import dis
>>>
>>> dis.dis(lambda : True and 0)
1 0 LOAD_CONST 2 (True)
3 JUMP_IF_FALSE_OR_POP 9
6 LOAD_CONST 1 (0)
>> 9 RETURN_VALUE
>>>
>>> True and 0
0
>>> 0 and True
0
>>>
similar to:
def exec_and(obj1, obj2):
if bool(obj1) != False:
return obj2
return obj1
With or, if the first expression is true, it gets popped immediately. If not, the second expression is poped, now the result really depends on the second.
>>> dis.dis(lambda : 0 or False)
1 0 LOAD_CONST 1 (0)
3 JUMP_IF_TRUE_OR_POP 9
6 LOAD_CONST 2 (False)
>> 9 RETURN_VALUE
>>>
>>> True or 0
True
>>> 1 or False
1
>>> False or 1
1
>>>
similar to:
def exec_or(obj1, obj2):
if bool(obj1) != True:
return obj2
return obj1
Consider the following use case:
element = dict.has_key('foo') and dict['foo']
Will set element to dict['foo'] if it exists, otherwise False. This is useful when writing a function to return a value or False on failure.
A further use case with or
print element or 'Not found!'
Putting these two lines together would print out dict['foo'] if it exists, otherwise it will print 'Not found!' (I use str() otherwise the or fails when element is 0 (or False) because that s considered falsey and since we are only printing it doesn't matter)
This can be simplified to
print dict.has_key('foo') and str(dict['foo']) or 'Not found!'
And is functionally equivalent to:
if dict.has_key('foo'):
print dict['foo']
else:
print 'Not found!'