Change repr of dict_keys, dict_values, and dict_items to use curly braces

[mr-nfamous]

BPO	31563
Nosy	@rhettinger, @serhiy-storchaka, @mr-nfamous

^{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 = <Date 2017-09-23.22:05:29.337>
created_at = <Date 2017-09-23.20:29:10.259>
labels = ['interpreter-core', 'type-feature', '3.7']
title = 'Change repr of dict_keys, dict_values, and dict_items to use curly braces'
updated_at = <Date 2017-09-23.22:05:29.335>
user = 'https://github.com/mr-nfamous'

bugs.python.org fields:

activity = <Date 2017-09-23.22:05:29.335>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2017-09-23.22:05:29.337>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2017-09-23.20:29:10.259>
creator = 'bup'
dependencies = []
files = []
hgrepos = []
issue_num = 31563
keywords = []
message_count = 3.0
messages = ['302803', '302807', '302813']
nosy_count = 3.0
nosy_names = ['rhettinger', 'serhiy.storchaka', 'bup']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue31563'
versions = ['Python 3.7']

[mr-nfamous]

They behave like sets yet their repr looks like a list: dict_keys([0, 1, 3, 4]). It should be dict_keys({0, 1, 2, 3, 4}). Ditto for odict_keys/odict_values. Maybe this is a holdover from when the repr of sets was Set([0, 1, 2, ...])?

The reason I bring this up is that they behave like sets was one of the last things I learned. I learned about stuff like abcs, metaclasses (including stuff like __prepare__ and __init_subclass__) and memorized practically all of the standard library long before I realized this.

I don't think it would break anything to do this and it could help dummies like me realize their set-like behavior sooner.

It might also be nice to give them the explicit symmetric_difference, union, and intersection methods in addition to the respective __xor__, __or__, and __and__ methods.

[rhettinger]

Some of these were Guido's design decisions made over a decade ago. He explicitly choose not have the spelled-out method names (both here in the concrete class and in the corresponding abstract base classes). It usually isn't a good idea to second guess his long standing decisions which have worked out well in practice.

From my own point-of-view, I prefer not to use the set curly brace notation in the repr for several reasons.

1. Ideally, the reprs for the keys(), values(), and items() should all have a similar look. The list notation is equally applicable to all of three, but the set notation isn't applicable to the values() which can have duplicates and may have non-hashable values.

2. The keys(), values(), and items() are guaranteed to be in the same order. The list notation reinforces this fact while the set notation does not.

3. There may be unforeseen usability issues (perhaps the change might falsely imply that there is an underlying set rather than a view of the dict, or perhaps it would imply that the full set() API is supported which it is not).

4. In Python 2, all three methods actually returned lists even though it would have been possible to return a set() for the keys. Though it isn't required, I do like the continuity in thought between the versions.

[serhiy-storchaka]

I concur with Raymond.

As for supporting the full set() API I thought about making unbound method set.union() and friends accepting arbitrary Set objects (or even arbitrary iterables), not just set objects, as a first argument. But I didn't investigate how this will affect the performance of the set objects.