classification
Title: Incorrect application of Argument Clinic to dict.pop()
Type: Stage: patch review
Components: Argument Clinic Versions: Python 3.9, Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: inada.naoki, larry, lukasz.langa, ned.deily, rhettinger, serhiy.storchaka, yselivanov
Priority: high Keywords: 3.8regression, patch

Created on 2019-06-08 18:48 by rhettinger, last changed 2019-07-02 06:40 by ned.deily.

Pull Requests
URL Status Linked Edit
PR 13933 open serhiy.storchaka, 2019-06-09 19:26
PR 13935 merged inada.naoki, 2019-06-10 02:07
Messages (9)
msg345062 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-06-08 18:48
help(dict.pop) was correct in 3.7:

    pop(...)
        D.pop(k[,d]) -> v

and incorrect for 3.8:

     pop(self, key, default=None, /)

This happened in:
     https://github.com/python/cpython/commit/9e4f2f3a6b8ee995c365e86d976937c141d867f8
     https://github.com/python/cpython/pull/12792

We've long known that the Argument Clinic was not applicable to all functions and methods, including this one in particular.  The issue is that the one argument form does not set the default to None; rather, it triggers a KeyError when the key is missing.  In other words, there is an important and long-standing semantic difference between d.pop(k) and d.pop(k,None).

When reverting this change, please add a note about why the ArgumentClinic is not being applied to this function until its capabilities have been built-out to handle functions that have different behaviors depending on the number of arguments.

Also, we should review other recent applications of the ArgumentClinic to make sure they didn't make the same mistake.
msg345072 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-06-09 05:49
The code generated by Argument Clinic is correct.

>>> {}.pop(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 1
>>> {}.pop(1, None)

It is just a signature wrong. Some earlier versions of Argument Clinic allowed you to write "default=undefined" to specify an optional argument without default value, but this feature was lost a long time ago. So now signatures of some functions with optional arguments are false.
msg345083 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-06-09 13:36
> It is just a signature wrong.

Yes, that is the part that needs to be fixed.  The information it provides is incorrect.  That is why this function wasn't converted long ago.
msg345084 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-06-09 15:40
I am working on this issue and almost done.

The questions is what inspect.Signature() and inspect.getfullargspec() should do with such functions.

1. Raise an exception as they did in old Python versions and as they do with builtin functions not converted to Argument Clinic.

2. Return a value where a special placeholder is used as a default value for optional parameters which cannot have a default value. In this case there are other questions: what is better name for it (I considered "unspecified" and "unrepresentable") and should it be a single object used for all parameters or a separate object created for every parameter?
msg345091 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-06-09 20:44
I would think that the best course of action is to revert the dict.pop() check-in for Python3.8, then reapply in 3.9 once a plan is worked out to expand the capabilities of the argument clinic and the expressiveness of signatures.  The latter seem more like enhancements that need time to mature rather than putting them in to 3.8b2.

There's no real downside to reverting the dict.pop() checkin.  It's only effects were to generate an incorrect signature and to make help() misleading.

The patch is too extensive for backporting to 3.8 and 3.7.
msg345104 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-06-10 04:15
PR 13933 implements the first option. It fixes similar issues with other functions so it should be backported to 3.7.

The second option is considered as a new feature and can go only in 3.9.
msg345139 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-06-10 19:15
As I noted on the PR: "I'm not going to get into whether this PR is appropriate for 3.8 but, assuming it were, I would be very concerned about making a change of this size and complexity in 3.7 at this stage in its lifecycle."
msg347109 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2019-07-02 06:32
I agree that this is a bug in many API docstrings, and PR 13933 is the right approach to fix all bugs in the future.

But in case of dict.pop(), this is not only a bug, but a regression.
May I merge PR-13935 to fix the regression in 3.7b2?
msg347111 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-07-02 06:40
I think you mean 3.8b2 so that would be Łukasz's call.
History
Date User Action Args
2019-07-02 06:40:58ned.deilysetmessages: + msg347111
2019-07-02 06:32:41inada.naokisetmessages: + msg347109
2019-06-10 19:15:51ned.deilysetnosy: + ned.deily, lukasz.langa
messages: + msg345139
2019-06-10 04:15:11serhiy.storchakasetmessages: + msg345104
2019-06-10 02:07:14inada.naokisetpull_requests: + pull_request13803
2019-06-09 20:44:32rhettingersetmessages: + msg345091
2019-06-09 19:26:39serhiy.storchakasetkeywords: + patch
stage: patch review
pull_requests: + pull_request13800
2019-06-09 15:40:19serhiy.storchakasetnosy: + yselivanov
messages: + msg345084
2019-06-09 13:36:12rhettingersetmessages: + msg345083
2019-06-09 05:49:36serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg345072
2019-06-08 18:50:59xtreaksetnosy: + inada.naoki
2019-06-08 18:48:05rhettingercreate