Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix inaccurate TypeError messages when calling with insufficient arguments #83381

Closed
jferard mannequin opened this issue Jan 3, 2020 · 11 comments
Closed

Fix inaccurate TypeError messages when calling with insufficient arguments #83381

jferard mannequin opened this issue Jan 3, 2020 · 11 comments
Labels
3.9 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@jferard
Copy link
Mannequin

jferard mannequin commented Jan 3, 2020

BPO 39200
Nosy @vstinner, @corona10, @pablogsal, @jferard
PRs
  • bpo-39200: Correct the error message for range() empty constructor #17813
  • bpo-39200: Correct the error message for min/max builtin function #17814
  • [3.8] bpo-39200: Correct the error message for range() empty constructor (GH-17813) #17940
  • [3.8] bpo-39200: Correct the error message for min/max builtin function (GH-17814) #17941
  • [3.7] bpo-39200: Correct the error message for range() empty constructor (GH-17813) #17942
  • [3.7] bpo-39200: Correct the error message for min/max builtin function (GH-17814) #17943
    		•

    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 2020-01-15.21:52:16.646>
created_at = <Date 2020-01-03.14:27:51.103>
labels = ['interpreter-core', 'type-feature', '3.9']
title = 'Fix inaccurate TypeError messages when calling with insufficient arguments'
updated_at = <Date 2020-01-16.00:48:35.445>
user = 'https://github.com/jferard'

    bugs.python.org fields:

    activity = <Date 2020-01-16.00:48:35.445>
actor = 'corona10'
assignee = 'none'
closed = True
closed_date = <Date 2020-01-15.21:52:16.646>
closer = 'vstinner'
components = ['Interpreter Core']
creation = <Date 2020-01-03.14:27:51.103>
creator = 'jferard'
dependencies = []
files = []
hgrepos = []
issue_num = 39200
keywords = ['patch']
message_count = 11.0
messages = ['359236', '359243', '359363', '359423', '359736', '359737', '359738', '359739', '359776', '360081', '360091']
nosy_count = 4.0
nosy_names = ['vstinner', 'corona10', 'pablogsal', 'jferard']
pr_nums = ['17813', '17814', '17940', '17941', '17942', '17943']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue39200'
versions = ['Python 3.9']
    @jferard
    Copy link
    Mannequin Author

    jferard mannequin commented Jan 3, 2020

    When passing no argument to range, the error message states that (exactly) one argument is expected.

    Actual:

        Python 3.9.0a0 (heads/master:d395209653, Jan  3 2020, 11:37:03)
    [GCC 7.4.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> range()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: range expected 1 argument, got 0

    Expected message:

    TypeError: range expected at least 1 argument, got 0

    (See for instance:

        >>> eval()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: eval expected at least 1 argument, got 0
)

    @jferard jferard mannequin added 3.7 (EOL) end of life 3.8 only security fixes 3.9 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels Jan 3, 2020
    @corona10
    Copy link
    Member

    corona10 commented Jan 3, 2020

    I noticed that min/max builtin function also has the same problem.

    For example, PyPy raise TypeError as
    TypeError: max() expects at least one argument.

    PR-17814 is an update patch for this.

    I suggest changing the title to be "Fix inaccurate TypeError messages when calling with insufficient arguments"

    @pablogsal pablogsal changed the title Inaccurate TypeError message for range without argument Fix inaccurate TypeError messages when calling with insufficient arguments Jan 3, 2020
    @pablogsal pablogsal changed the title Inaccurate TypeError message for range without argument Fix inaccurate TypeError messages when calling with insufficient arguments Jan 3, 2020
    @pablogsal
    Copy link
    Member

    New changeset 4b66fa6 by Pablo Galindo in branch 'master':
    bpo-39200: Correct the error message for range() empty constructor (GH-17813)
    4b66fa6

    @corona10
    Copy link
    Member

    corona10 commented Jan 6, 2020

    @pablogsal
    PR 17813 is merged.
    If you don't mind, can we review PR 17814 that will be applied or not?

    @vstinner
    Copy link
    Member

    New changeset abdc634 by Victor Stinner (Dong-hee Na) in branch 'master':
    bpo-39200: Correct the error message for min/max builtin function (GH-17814)
    abdc634

    @vstinner
    Copy link
    Member

    Dong-hee, Pablo: Should we backport the two fixes to 3.7 and 3.8 branches? IMHO yes, we should backport.

    @corona10
    Copy link
    Member

    Victor: Changes are only correcting the message.
    I am +1 on backporting :)

    @vstinner
    Copy link
    Member

    Backport PRs are ready for 3.7 and 3.8. Question: is there a risk of breaking the backward compatibility if a project unit test rely on the exact error message? If yes, maybe it's better to reject the backports and close this issue (only change the error message in 3.9).

    @corona10
    Copy link
    Member

    CPython or stdlib: There is no code depends on the error message of range and min/max.
    3rd party: IMHO, if somebody relies on the error message, not error type, I think that the code pattern is bad usage

    And as I mentioned on msg359243, other python compatible compilers/interpreters already don't follow the same error message as CPython.
    If the issue had been caused by this issue, it would have already been reported. But it doesn't seem to be.

    So my conclusion is that it will not be a problem. :)

    @vstinner
    Copy link
    Member

    3rd party: IMHO, if somebody relies on the error message, not error type, I think that the code pattern is bad usage

    I don't think that we can be pedantic on how projects should be tested.

    IMHO it's too risky. I rejected backports. The risk of regression in a *minor* release is just too high. Such "cleanup" change is better fitted for a new 3.x major release.

    @vstinner vstinner removed 3.7 (EOL) end of life 3.8 only security fixes labels Jan 15, 2020
    @vstinner vstinner removed 3.7 (EOL) end of life 3.8 only security fixes labels Jan 15, 2020
    @corona10
    Copy link
    Member

    Thanks for the opinion.
    Sounds reasonable!

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    3.9 only security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    3 participants
    @vstinner @corona10 @pablogsal