Repository navigation
Improve documentation for list methods that compare items by equality #73942
Description
Activity
atodorov commented
on Mar 8, 2017 atodorovmannequinMannequinAuthorWhen using list.count() I get the following results
>>> [1, 2, 3].count(1) 1 >>> [1, 2, 3, True].count(2) 1 >>> [1, 2, 3, True].count(True) 2 >>> [1, 2, 3, True].count(1) 2as you can see True is considered the same as 1. The documentation for the count method says:
count(...) L.count(value) -> integer -- return number of occurrences of value
so IMO the above behavior is wrong. Seeing this on a RHEL 7 system with
Python 3.5.1 and 2.7.5bools are subclasses of int and False and True have integer equivalents:
https://docs.python.org/3/library/stdtypes.html#bltin-boolean-values
Further to Barry's explanation, you see the same result with any values which compare equal:
py> from decimal import Decimal as D
py> [1, 1.0, D(1), True, 1+0j].count(D(1))
5This is standard behaviour for methods
count,remove, andindex, but it isn't explained well in the documentation. E.g.removesays "Remove the first item from the list whose value is x` which could be read as meaning that the test is done by identity. All three methods need to clarify that ordinary == equality is used.I'm going to re-open the task as a documentation issue.
- changed the title
[-]List count() counts True as 1[/-][+]Improve documentation for list methods that compare items by equality[/+]on Mar 8, 2017 To be clear, I'm referring to the docs in the tutorial:
https://docs.python.org/3.7/tutorial/datastructures.html
and the docstrings as well as the library reference:
https://docs.python.org/3.7/library/stdtypes.html#sequence-types-list-tuple-range
The library reference already notes that
removeuses equality, but the others do not.MojoVampire commented
on Mar 8, 2017 MojoVampiremannequinMannequinSteven: Technically, in CPython, they use both identity and equality testing, as a function of using RichCompareBool (which tests identity first, then equality), rather than RichCompare (which only tests equality).
It makes a difference for stuff like NaN values, where describing it as equality only would imply that:
nan = float('nan') ([nan] * 10).count(nan)
produces 0 (because nan is equal to nothing, including itself), when in fact it produces 10 (because we reused the same nan object, and the identity test passed).
+1 for jsoh. Actually the behaviour is documented in https://docs.python.org/3/reference/expressions.html#value-comparisons.
So a single 'a is b' or 'a == b' is not complete. I would like to use 'equal to' which implies 'a is b or a == b'.
atodorov commented
on Mar 12, 2017 atodorovmannequinMannequinAuthorHi folks,
I have another very similar issue, it could be the same root cause. Let me know if it is.assert 3 == 3.0 will pass
self.assertEqual(3, 3.0) - will pass
this had the nasty side effect of my test suite not catching a problem with SUT. I have updated the test suite to validate the result type as well but want to know how to file this use-case.
I'm afraid I don't know what SUT means.
But 3 == 3.0 is the correct and expected behaviour. If you need to
check that two values are both the same type and the same value, you
have to validate the type and value separately.Changing the behaviour of == is ruled out for backwards
compatability, but perhaps you could suggest a new === operator
to check type and value. That would require some discussion on
the Python Ideas mailing list, not just a feature request on the
tracker.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: