Repository navigation
Better document mixed-type comparison of set items, dict keys #77753
Description
Activity
JanuszHarkot commented
on May 18, 2018 JanuszHarkotmannequinMannequinAuthorusing boolean (True/False) as dictionary keys, coerce them to integers - is this behavior documented somewhere?
I know that asking to fix this is not easy fix, but shouldn't this be highlighted everywhere with red flags and warnings, so people will know that this is expected?
Python 3.6.5 (default, Mar 29 2018, 03:28:50) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> dta = {False: 'false', True: 'true', 0: 'zero', 1: 'one'} >>> print(dta[False]) zero >>>
JanuszHarkot commented
on May 18, 2018 JanuszHarkotmannequinMannequinAuthorPython 3.6.5 (default, Mar 29 2018, 03:28:50) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> dta = {False: 'false', True: 'true', 0: 'zero', 1: 'one'} >>> print(dta[False]) zero >>> dta {False: 'zero', True: 'one'} >>>
It's documented here: https://docs.python.org/3/library/stdtypes.html#mapping-types-dict
Numeric types used for keys obey the normal rules for numeric
comparison: if two numbers compare equal (such as 1 and 1.0) then
they can be used interchangeably to index the same dictionary entry.Since False == 0, False and 0 are interchangeable as dictionary keys. Similarly for True and 1. Note that the dictionary you created only actually has two entries:
>>> dta = {False: 'false', True: 'true', 0: 'zero', 1: 'one'} >>> dta {False: 'zero', True: 'one'}
Though calling out numeric types in particular in the docs does feel a little odd to me: the rule is that *any* two hashable objects that compare equal should be interchangeable for the purposes of dictionary lookup (or set membership, come to that). There's nothing particularly special about numbers in this context.
Mark, are you suggesting a doc addition (and a change of Components) or should we close this as 'not a bug'?
I expect these docs date back to when ints, longs, and floats were the only hashable language-supplied types for which mixed-type comparison could ever return True.
They could stand some updates ;-)
fractions.Fractionanddecimal.Decimalare more language-supplied numeric types that participate now, and the Boolean singletons are instances of (a subclass of)int. I think it would be good to point that out, especially the latter (in many other languages Booleans can't be compared to ints).So +1 both to Mark's more-general explanation, and to explicitly naming more specific cases for illustration.
With Tim's addition
>>> from fractions import Fraction as F >>> from decimal import Decimal as D >>> s = {0, 1, 0.0, 1.0, F(0,1), F(1, 1), D(0), D(1), False, True} >>> s {0, 1}
I think we should consider moving the main discussion of the general comparison and hashing principle and example to the set entry. (Sets ars simpler and are when people new to Python already know about.) Point out that for displays, the first of equals is kept and not replaced (this is also true of dicts). Then, in the dict entry, say that dict keys are treated like set items, give an equivalent dict example, and link to the discussion of set items.
>>> x = None >>> d = {0:x, 1:x, 0.0:x, 1.0:x, F(0,1):x, F(1, 1):x, D(0):x, D(1):x, False:x, True:x} >>> d {0: None, 1: None} >>>
- changed the title
[-]False/True as dictionary keys treated as integers[/-][+]Better document mixed-type comparison of set items, dict keys[/+]on May 18, 2018 @slateny I'm not seeing the applicability of that comment to this issue. I think it's still true that the docs here could use an update.
Proposed minimal edit: replace the sentence
Numeric types used for keys obey the normal rules for numeric comparison: if two numbers compare equal (such as 1 and 1.0) then they can be used interchangeably to index the same dictionary entry.
with
If two values compare equal (such as 1 and 1.0) then they can be used interchangeably to index the same dictionary entry.
Hmm I see, so the improvement would be to generalize the statement. Do you think there's any value in adding any examples, or extending the note in the parenthesis a bit and say
... equal (such as 1, 1.0, and True) then they ...to emphasize that point?Hmm I see, so the improvement would be to generalize the statement.
Yes, I suppose; though it's more about removing an overly-specific specialisation.
Adding
Trueinto the parenthetical sounds reasonable to me.If it were up to me, I'd also remove the "usually unwise to use floating-point numbers as dictionary keys" sentence - that doesn't seem to be a trap that people fall into often enough to make it worth calling out in the docs. (And I'd dispute the "usually", too.)
- added 4 commits that reference this issue
on Oct 26, 2022
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: