classification
Title: ambiguous documentation for dict.popitem
Type: Stage: resolved
Components: Documentation Versions: Python 3.8, Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: arigo, bup, docs@python, inada.naoki, rhettinger
Priority: normal Keywords: patch

Created on 2018-07-16 06:00 by bup, last changed 2018-07-17 02:08 by rhettinger. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 8292 merged rhettinger, 2018-07-16 07:12
PR 8307 merged miss-islington, 2018-07-17 00:20
Messages (8)
msg321708 - (view) Author: Dan Snider (bup) * Date: 2018-07-16 06:00
https://docs.python.org/3/library/stdtypes.html#dict.popitem


`dict.popitem` no longer returns an "arbitrary" (key, value) pair as the documentation suggests. Rather, it always returns the pair whose key was most recently *inserted* (ie., the last entry in `dk_entries`).

Perhaps the docs could reflect that this method is now always LIFO rather arbitrary now that insertion order is guaranteed?
msg321709 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2018-07-16 06:07
I think it is implementation detail yet.
Only iteration order is guaranteed.
msg321712 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-07-16 06:52
My opinion is that it is in fact guaranteed. It makes no sense for all other aspects of the dict behavior to be guaranteed and not this one.  This is what PyPy and CPython already do and there is no scenario where an implementation would be able to append a new pair at the end but unable to reverse the operation.

IMO, leaving this in an ambiguous state would created problems unnecessarily and it would preclude reasonable uses of the the ordering feature.
msg321714 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2018-07-16 07:15
@Armin Rigo
How do you think about this?
Is there no possible optimizations by breaking LIFO dict.popitem()?
msg321716 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-07-16 07:57
> Is there no possible optimizations by breaking LIFO dict.popitem()?

Even if there were a possible optimization, we wouldn't care.  The API is too desirable to forgo in the name of micro-optimization.  We don't design our APIs that way -- trading the relevant and actionable for ethereal and unknown.

Also, it is common sense that addition of a key/value pair at the end is a readily undoable operation (no more expensive to remove than it was to add). There will be a dummy entry in the hash array just like there is now.
msg321741 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2018-07-16 16:02
Agreed with Raymond.
msg321782 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-07-17 00:20
New changeset 01b7d5898262dbe0e9edb321b3be9a34da196f6f by Raymond Hettinger in branch 'master':
bpo-34123: Fix missed documentation update for dict.popitem(). (GH-8292)
https://github.com/python/cpython/commit/01b7d5898262dbe0e9edb321b3be9a34da196f6f
msg321787 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-07-17 02:08
New changeset bfa8a358e2cec40484c4655138ca3c6b10f8462a by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-34123: Fix missed documentation update for dict.popitem(). (GH-8292) (GH#8307)
https://github.com/python/cpython/commit/bfa8a358e2cec40484c4655138ca3c6b10f8462a
History
Date User Action Args
2018-07-17 02:08:43rhettingersetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2018-07-17 02:08:22rhettingersetmessages: + msg321787
2018-07-17 00:20:44miss-islingtonsetpull_requests: + pull_request7842
2018-07-17 00:20:19rhettingersetmessages: + msg321782
2018-07-16 16:02:01arigosetmessages: + msg321741
2018-07-16 07:57:49rhettingersetmessages: + msg321716
2018-07-16 07:15:43inada.naokisetnosy: + arigo
messages: + msg321714
2018-07-16 07:12:10rhettingersetkeywords: + patch
stage: patch review
pull_requests: + pull_request7826
2018-07-16 06:58:25rhettingersetassignee: docs@python -> rhettinger
2018-07-16 06:52:14rhettingersetnosy: + rhettinger
messages: + msg321712
2018-07-16 06:07:09inada.naokisetnosy: + inada.naoki
messages: + msg321709
2018-07-16 06:00:27bupcreate