dict.fromkeys insertion order

[vedgar]

BPO	45908
Nosy	@rhettinger, @methane, @serhiy-storchaka, @vedgar

^{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 = 'https://github.com/rhettinger'
closed_at = <Date 2021-11-27.20:39:10.617>
created_at = <Date 2021-11-27.08:02:49.205>
labels = ['3.11', 'invalid', '3.10', 'docs']
title = 'dict.fromkeys insertion order'
updated_at = <Date 2021-11-27.20:42:15.017>
user = 'https://github.com/vedgar'

bugs.python.org fields:

activity = <Date 2021-11-27.20:42:15.017>
actor = 'rhettinger'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2021-11-27.20:39:10.617>
closer = 'rhettinger'
components = ['Documentation']
creation = <Date 2021-11-27.08:02:49.205>
creator = 'veky'
dependencies = []
files = []
hgrepos = []
issue_num = 45908
keywords = []
message_count = 5.0
messages = ['407136', '407146', '407153', '407166', '407167']
nosy_count = 5.0
nosy_names = ['rhettinger', 'methane', 'docs@python', 'serhiy.storchaka', 'veky']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue45908'
versions = ['Python 3.10', 'Python 3.11']

[vedgar]

I'm sure this is exactly how it should work, I just want to know if you think it is documented properly, so I can rely on it. In my opinion the docs should be more precise.

>>> ''.join(dict.fromkeys('axbxc'))
'axbc'

Is this guaranteed by the documentation? Of course, dict iteration order is now guaranteed to be insertion order, but still, nowhere do the docs say that fromkeys inserts the keys into new dictionary in order in which they appear in its argument.

(Probably the reason for this is that dict iteration order was fixed in 3.7, yet fromkeys existed a long time before that.)

I propose an addition to the documentation:

Create a new dictionary with keys from iterable (in order) and values set to value.

https://docs.python.org/3/library/stdtypes.html

[rhettinger]

All the dict methods retain insertion order. There is nothing special about fromkeys().

[vedgar]

Absolutely, but that's not my problem. I take your sentence to mean that when I do something with a _dict_ argument, it should try to preserve its insertion order as much as possible (given the semantics of the concrete method in question). I agree.

But my question is about constructing a dict from something other than a dict (here, a str, simply because it's easiest to visualize). I'm sure you don't mean to say dict.fromkeys retains the insertion order of its argument always, since it's obviously false if you give it a set.

What I'd like to be specified here (or elsewhere, but here I think it's useful) is that iteration order of the argument to dict.fromkeys is preserved as insertion order (and therefore iteration order) of the resulting dict. Besides, I don't see any other point where it should be specified... the only other constructor, dict itself, gives a very precise description (https://docs.python.org/3/library/stdtypes.html#dict) of how it creates a dict from its argument(s). Of course, there it mattered even before Py3.7, since values were important. In dict.fromkeys values are all the same, but order still matters and should (IMO) be specified.

[rhettinger]

Thanks for the suggestion but I’m going to decline. We has many APIS that consume an iterable and all of them do so In iteration order. Even the regular dict() constructor takes an iterable of tuples and adds them in iteration order. Also, I’m not concerned because of our experience with OrderedDict() which for a decade had a fromkeys() method and there has never been a question about it. There was even an idiom for deducing a list while maintaining order: list(OrderedDict.fromkeys(seq)).

[serhiy-storchaka]

What else can it be? dict.fromkeys() adds keys in the order of obtaining them, and it obtains them by iterating its argument. If we need a special note here, we need a special note for list(), tuple(), filter(), enumerate() and all other functions which consume an iterable.