This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Change repr of dict_keys, dict_values, and dict_items to use curly braces
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.7
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: bup, rhettinger, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-09-23 20:29 by bup, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg302803 - (view) Author: Dan Snider (bup) * Date: 2017-09-23 20:29
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.
msg302807 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-09-23 21:22
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.
msg302813 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-09-23 22:05
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.
Date User Action Args
2022-04-11 14:58:52adminsetgithub: 75744
2017-09-23 22:05:29serhiy.storchakasetstatus: open -> closed

nosy: + serhiy.storchaka
messages: + msg302813

resolution: rejected
stage: resolved
2017-09-23 21:22:05rhettingersetnosy: + rhettinger
messages: + msg302807
components: + Interpreter Core
2017-09-23 20:29:10bupcreate