Issue 39200: Fix inaccurate TypeError messages when calling with insufficient arguments

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
)

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"

New changeset 4b66fa6ce9c37e70b55af220d0e07368319de803 by Pablo Galindo in branch 'master':
bpo-39200: Correct the error message for range() empty constructor (GH-17813)
https://github.com/python/cpython/commit/4b66fa6ce9c37e70b55af220d0e07368319de803

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

New changeset abdc634f337ce4943cd7d13587936837aac2ecc9 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39200: Correct the error message for min/max builtin function (GH-17814)
https://github.com/python/cpython/commit/abdc634f337ce4943cd7d13587936837aac2ecc9

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

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

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).

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. :)

> 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.

Thanks for the opinion.
Sounds reasonable!

resolution: fixed
stage: patch review -> resolved

messages: + msg359243
versions: + Python 3.5, Python 3.6