Better document mixed-type comparison of set items, dict keys

[JanuszHarkot]

BPO	33572
Nosy	@tim-one, @terryjreedy, @mdickinson

^{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']

[JanuszHarkot]

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]

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]

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]

Mark, are you suggesting a doc addition (and a change of Components) or should we close this as 'not a bug'?

[tim-one]

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]

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}
>>>

[slateny]

Per comment, I'll close this if there aren't any objections.

[mdickinson]

@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]

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]

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.)