We Keep Coding

Comparing closures in Python

My goal is to compare two bounded closures and check if they are bounded with the same input argument len
def foo(len: int):
def foob():
return len
return foob
a = foo(1)
b = foo(1)
print(a == b)
The output is False.
But when I check for equality using the following,
print(a.__closure__ == b.__closure__)
the output appears to be True and False when the input argument len is different (just as I want it to work). The problem comes when I am traversing through a large dictionary of such function closure signature where __eq__ is checked for instead of __closure__. Is there any way to get around this?
UPDATE: There was a lack of clarity in the problem.
If I were to do something like this:
a_dict[foo(1)] = 0x12
It would create a new closure object for foo(1) even if foo(1) were present in the dictionary as it checks using __eq__ method.

Why does ... == True return False in Python 3?

I am learning python, but I'm a bit confused by the following result.
In [41]: 1 == True
Out[41]: True
In [42]: if(1):
...: print('111')
...:
111
In [43]: ... == True
Out[43]: False <===== why this is False while '1 == True' is True in previous sample
In [44]: if (...): <==== here ... just behaves like True
...: print('...')
...:
...
According to the documentation, ... has a truth value of True.
But I still feel the above code a bit inconsistent.
...And something more interesting:
In [48]: 2==True
Out[48]: False <===== why 1==True returns True while 2==True returns False?
In [49]: if(2):
...: print('222')
...:
222

You're mixing two concepts: equality testing and truth-value testing. They are not the same in Python.
I think what triggered the question is that Python does an implicit casting when you do if something (it casts the something to bool) but it does not do implicit casting when you do something1 == something2.
Pythons data model actually explains how these operations are done:
Truth-value testing
It starts by checking if the object implements the __bool__ method and if it does it uses the returned boolean.
If it doesn't define a __bool__ method it looks at the __len__ method. If it's implemented it will use the result of len(obj) != 0.
If it doesn't have either the object is considered True.
For integers the __bool__ method returns True except when the integer value is 0 (then it's False).
The Ellipsis object (... is the Ellipsis object) on the other hand doesn't implement __bool__ or __len__ so it's always True.
Equality testing
Equality testing relies on the __eq__ method of both arguments. It's more a chain of operations:
It checks if the first operand implements __eq__ when the second operand is passed as argument.
If it doesn't then it checks if the second operand implements __eq__ when the first operand is passed as argument.
If it doesn't then Python checks for object identity (if they are the same object - similar to pointer comparisons in C-like languages)
The order of these operations may vary.1
For built-in Python types these operations are explicitly implemented. For example integers implement __eq__ but the CHECK_BINOP makes sure that it returns NotImplemented if the other one isn't an integer.
The Ellipsis object doesn't implement __eq__ at all.
So when you compare integers and Ellipsis Python will always fallback to object identity and so it will always return False.
On the other hand booleans are a subclass of integers so they actually compare with int (they are another int after all). The booleans are implemented as 1 (True) and 0 (False). So they compare equal:
>>> 1 == True
True
>>> 0 == False
True
>>> 1 == False
False
>>> 0 == True
False
Even though the source code is probably hard to understand I hope I explained the concepts well enough (the source code is for the CPython implementation, the implementation in other Python implementations like PyPy, IronPython may differ!). The important take-away message should be that Python doesn't do implicit conversions in equality checks and equality testing is not related to truth value testing at all. The built-in types are implemented that they almost always give senseable results:
all number-types implement equality in some way (floats compare to integers, complex compare to integers and floats)
and everything not-zero and not-empty is truthy.
However if you create your own classes you can override equality and truth value testing as you like (and then you can spread a lot of confusion)!
1 In some cases the order is changed:
If the second operand is a subclass of the first operand the first two steps are reversed.
For some implicit equality checks the object identity is checked before any __eq__ methods are called. For example when checking if some item is in a list, i.e. 1 in [1,2,3].

Any object can be tested for "truthiness":
Any object can be tested for truth value, for use in an if or while condition or as operand of the Boolean operations below. The following values are considered false:
None
False
zero of any numeric type, for example, 0, 0.0, 0j.
any empty sequence, for example, '', (), [].
any empty mapping, for example, {}.
instances of user-defined classes, if the class defines a bool() or len() method, when that method returns the integer zero or bool value False. [1]
All other values are considered true — so objects of many types are always true.
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.)
So it's not hard to see that if ... will enter the branch. The Ellipsis object is considered true. However that doesn't mean it has to be equal to True. Just the bool(...) == True!
The if will implicitly call bool on the condition, so:
if ...:
# something
will be evaluated as if you had written:
if bool(...):
# something
and:
>>> bool(...)
True
>>> bool(1)
True
>>> bool(2)
True
However there's one catch here. True is equal to 1 and False equal to 0, but that's just because bool subclasses integer in python.

In python most (all?) objects have a bool value. The meaning behind "has a truth value of True" means that bool(obj) evaluates to True.
On the other hand, True is treated as 1 in many cases (and False as 0) which you can see when you do stuff like:
sum([True, True, False])
# (1 + 1 + 0) -> 2
That is why you get 1 == True --> True
There is a more explicit explanation in the documentation:
Boolean values are the two constant objects False and True. They are used to represent truth values (although other values can also be considered false or true). In numeric contexts (for example when used as the argument to an arithmetic operator), they behave like the integers 0 and 1, respectively
From the type-hierarchy itself in the docs:
These represent the truth values False and True. The two objects representing the values False and True are the only Boolean objects. The Boolean type is a subtype of the integer type, and Boolean values behave like the values 0 and 1, respectively, in almost all contexts, the exception being that when converted to a string, the strings "False" or "True" are returned, respectively.

I believe it's 1 == True here is that's weird, not that ... != True.
1 equals with True because in Python booleans are subclass of integers (because of PEP-285). See yourself:
>>> issubclass(bool, int)
True

Why is there a not equal operator in python [duplicate]

This question already has answers here:
Why does Python have an __ne__ operator method instead of just __eq__?
(3 answers)
Closed 7 years ago.
I was wondering about the reason of having a not equal operator in python.
The following snipped:
class Foo:
def __eq__(self, other):
print('Equal called')
return True
def __ne__(self, other):
print('Not equal called')
return True
if __name__ == '__main__':
a = Foo()
print(a == 1)
print(a != 1)
print(not a == 1)
outputs:
Equal called
True
Not equal called
True
Equal called
False
Doesn't this actually invite a lot of trouble by potentially saying:
A == B and A != B
can be correct at the same time. Furthermore this introduces a potential pitfall when forgetting to implement __ne__.

Depending on one's needs there are cases where equal and not equal are not opposite; however, the vast majority of cases they are opposite, so in Python 3 if you do not specify a __ne__ method Python will invert the __eq__ method for you.
If you are writing code to run on both Python 2 and Python 3, then you should define both.

Per the data model documentation, which covers the "magic methods" you can implement on classes (emphasis mine):
There are no implied relationships among the comparison operators. The
truth of x==y does not imply that x!=y is false. Accordingly, when
defining __eq__(), one should also define __ne__() so that the
operators will behave as expected.

Seems you are returning True instead of doing the comparison.

python or on operator module [duplicate]

This question already has answers here:
Why doesn't the operator module have a function for logical or?
(3 answers)
Closed 6 years ago.
On the operator module, we have the or_ function, which is the bitwise or (|).
However I can't seem to find the logical or (or).
The documentation doesn't seem to list it.
I'm wondering why isn't it included? Is it not considered a operator?
Is there a builtin function that provides its behaviour?

The or operator short circuits; the right-hand expression is not evaluated when the left-hand returns a true value. This applies to the and operator as well; when the left-hand side expression returns a false value, the right-hand expression is not evaluated.
You could not do this with a function; all operands have to be evaluated before the function can be called. As such, there is no equivalent function for it in the operator module.
Compare:
foo = None
result = foo and foo(bar)
with
foo = None
result = operator.boolean_and(foo, foo(bar)) # hypothetical and implementation
The latter expression will fail, because you cannot use None as a callable. The first version works, because the and operator won't evaluate the foo(bar) expression.

The closest thing to a built-in or function is any:
>>> any((1, 2))
True
If you wanted to duplicate or's functionality of returning non-boolean operands, you could use next with a filter:
>>> next(operand for operand in (1, 2) if operand)
1
But like Martijn said, neither are true drop-in replacements for or because it short-circuits. A true or function would have to accept functions to be able to avoid evaluating all the results:
logical_or(lambda: 1, lambda: 2)
This is somewhat unwieldy, and would be inconsistent with the rest of the operator module, so it's probably best that it's left out and you use other explicit methods instead.

It's not possible:
This can explicitly be found in the docs:
The expression x or y first evaluates x; if x is true, its value is
returned; otherwise, y is evaluated and the resulting value is
returned.
It does not exist as an operator function because due to the language specification, it is impossible to implement because you cannot delay execution of a called argument when calling the function. Here is an example of or in action:
def foo():
return 'foo'
def bar():
raise RuntimeError
If bar is called, we get a Runtime error. And looking at the following line, we see that Python shortcuts the evaluation of the line, since foo returns a True-ish value.
>>> foo() or bar()
'foo'
We can approximate:
We can simulate this behavior by passing in uncalled functions, and then calling them inside our or function:
def my_or(*funcs):
for func in funcs:
call = func()
if call:
return call
return call
>>> my_or(foo, bar)
'foo'
But you cannot shortcut execution of called callables that are passed to a function:
>>> my_or(foo, bar())
Traceback (most recent call last):
File "<pyshell#28>", line 1, in <module>
like_or(foo, bar())
File "<pyshell#24>", line 2, in bar
raise RuntimeError
RuntimeError
So it would be improper to include such a function in the built-ins or standard library because users would expect an or function to work just as a boolean or test, which again, is impossible.

The reason you are getting 1 after executing >>> 1 or 2 is because 1 is true so the expression has been satisfied.
It might make more sense if you try executing >>> 0 or 2. It will return 2 because the first statement is 0 or false so the second statement gets evaluated. In this case 2 evaluates to a true boolean value.
The and and or operators evaluate the first value and then plug the result into the "AND and OR" truth tables. In the case of and the second value is only considered if the first evaluates to true. In the case of the or operator, if the first value evaluates to true the expression is true and can return, if it isn't the second value is evaluated.

Python things which are neither True nor False

I just found this :
a = (None,)
print (a is True)
print (a is False)
print (a == True)
print (a == False)
print (a == None)
print (a is None)
if a : print "hello"
if not a : print "goodbye"
which produces :
False
False
False
False
False
False
hello
So a neither is, nor equals True nor False, but acts as True in an if statement.
Why?
Update :
actually, I've just realized that this isn't as obscure as I thought. I get the same result for a=2, as well (though not for a=0 or a=1, which are considered equal to False and True respectively)

I find almost all the explanations here unhelpful, so here is another try:
The confusion here is based on that testing with "is", "==" and "if" are three different things.
"is" tests identity, that is, if it's the same object. That is obviously not true in this case.
"==" tests value equality, and obviously the only built in objects with the values of True and False are the object True and False (with the exception of the numbers 0 and 1, of any numeric type).
And here comes the important part:
'if' tests on boolean values. That means that whatever expression you give it, it will be converted to either True or False. You can make the same with bool(). And bool((None,)) will return True. The things that will evaluate to False is listed in the docs (linked to by others here)
Now maybe this is only more clear in my head, but at least I tried. :)

a is a one-member tuple, which evaluates to True. is test identity of the object, therefore, you get False in all those test. == test equality of the objects, therefore, you get False again.
in if statement a __bool__ (or __nonzero__) used to evaluate the object, for a non-empty tuple it should return True, therefore you get True. hope that answers your question.
edit: the reason True and False are equal to 1 and 0 respectively is because bool type implemented as a subclass of int type.

Things in python don't have to be one of True or False.
When they're used as a text expression for if/while loops, they're converted to booleans. You can't use is or == to test what they evaluate to. You use bool( thing )
>>> a = (None,)
>>> bool(a)
True
Also note:
>>> 10 == True
False
>>> 10 is True
False
>>> bool(10)
True

TL;DR:
if and == are completely different operations. The if checks the truth value of a variable while == compares two variables. is also compares two variables but it compares if both reference the same object.
So it makes no sense to compare a variable with True, False or None to check it's truth value.
What happens when if is used on a variable?
In Python a check like if implicitly gets the bool of the argument. So
if something:
will be (under the hood) executed like:
if bool(something):
Note that you should never use the latter in your code because it's considered less pythonic and it's slower (because Python then uses two bools: bool(bool(something))). Always use the if something.
If you're interested in how it's evaluated by CPython 3.6:
Note that CPython doesn't exactly use hasattr here. It does check if the type of x implements the method but without going through the __getattribute__ method (hasattr would use that).
In Python2 the method was called __nonzero__ and not __bool__
What happens when variables are compared using ==?
The == will check for equality (often also called "value equality"). However this equality check doesn't coerce the operands (unlike in other programming languages). The value equality in Python is explicitly implemented. So you can do:
>>> 1 == True # because bool subclasses int, True is equal to 1 (and False to 0)
True
>>> 1.0 == True # because float implements __eq__ with int
True
>>> 1+1j == True # because complex implements __eq__ with int
True
However == will default to reference comparison (is) if the comparison isn't implemented by either operand. That's why:
>>> (None, ) == True
False
Because tuple doesn't "support" equality with int and vise-versa. Note that even comparing lists to tuples is "unsupported":
>>> [None] == (None, )
False
Just in case you're interested this is how CPython (3.6) implements equality (the orange arrows indicate if an operation returned the NotImplemented constant):
That's only roughly correct because CPython also checks if the type() of value1 or value2 implements __eq__ (without going through the __getattribute__ method!) before it's called (if it exists) or skipped (if it doesn't exist).
Note that the behavior in Python2 was significantly more lengthy (at least if the methods returned NotImplemented) and Python 2 also supported __cmp__,
What happens when variables are compared using is?
is is generally referred to as reference equality comparison operator. It only returns True if both variables refer to exactly the same object. In general variables that hold the same value can nevertheless refer to different objects:
>>> 1 is 1. # same value, different types
False
>>> a = 500
>>> a is 500 # same value, same type, different instances
False
Note that CPython uses cached values, so sometimes variables that "should" be different instances are actually the same instance. That's why I didn't use 500 is 500 (literals with the same value in the same line are always equal) and why I couldn't use 1 as example (because CPython re-uses the values -5 to 256).
But back to your comparisons: is compares references, that means it's not enough if both operands have the same type and value but they have to be the same reference. Given that they didn't even have the same type (you're comparing tuple with bool and NoneType objects) it's impossible that is would return True.
Note that True, False and None (and also NotImplemented and Ellipsis) are constants and singletons in CPython. That's not just an optimization in these cases.

(None,) is a tuple that contains an element, it's not empty and therefore does not evaluate to False in that context.

Because a=(None,) is a tuple containing a single element None
Try again with a=None and you will see there is a different result.
Also try a=() which is the empty tuple. This has a truth value of false

In Python every type can be converted to bool by using the bool() function or the __nonzero__ method.
Examples:
Sequences (lists, strings, ...) are converted to False when they are empty.
Integers are converted to False when they are equal to 0.
You can define this behavior in your own classes by overriding __nonzero__().
[Edit]
In your code, the tuple (None,) is converted using bool() in the if statements. Since it's non-empty, it evaluates to True.