GeezerVison is showing github.com — Better document mixed-type comparison of set items, dict keys · Issue #77753 · python/cpython
Better document mixed-type comparison of set items, dict keys #77753Description
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:
assignee = None
closed_at = None
created_at = <Date 2018-05-18.15:19:50.946>
labels = ['type-bug', 'docs']
title = 'Better document mixed-type comparison of set items, dict keys'
updated_at = <Date 2018-05-18.19:44:10.802>
user = 'https://bugs.python.org/JanuszHarkot' bugs.python.org fields:
activity = <Date 2018-05-18.19:44:10.802>
actor = 'terry.reedy'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation']
creation = <Date 2018-05-18.15:19:50.946>
creator = 'Janusz Harkot'
dependencies = []
files = []
hgrepos = []
issue_num = 33572
keywords = []
message_count = 6.0
messages = ['317032', '317033', '317035', '317045', '317046', '317053']
nosy_count = 5.0
nosy_names = ['tim.peters', 'terry.reedy', 'mark.dickinson', 'docs@python', 'Janusz Harkot']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33572'
versions = ['Python 3.6'] ActivityJanuszHarkot commented on May 18, 2018 MannequinAuthor More actions using 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 MannequinAuthor More actions 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
>>> dta
{False: 'zero', True: 'one'}
>>>mdickinson commented on May 18, 2018 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. terryjreedy commented on May 18, 2018 Mark, are you suggesting a doc addition (and a change of Components) or should we close this as 'not a bug'? tim-one commented on May 18, 2018 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.Fraction and decimal.Decimal are 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. terryjreedy commented on May 18, 2018 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, 2018slateny commented on Jul 12, 2022 Per comment, I'll close this if there aren't any objections. mdickinson commented on Jul 12, 2022 @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.
slateny commented on Jul 13, 2022 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? mdickinson commented on Jul 14, 2022
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 True into 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.)
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|