"ValueError: min() arg is an empty sequence" is wrong (builtins.min/max)

[Nnarol]

BPO	46671
Nosy	@Nnarol
PRs	GH-90829: Fix empty iterable error message in min/max #31181

^{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 = None
created_at = <Date 2022-02-07.00:22:26.157>
labels = ['interpreter-core', 'type-bug', '3.11']
title = '"ValueError: min() arg is an empty sequence" is wrong (builtins.min/max)'
updated_at = <Date 2022-02-07.00:52:23.413>
user = 'https://github.com/Nnarol'

bugs.python.org fields:

activity = <Date 2022-02-07.00:52:23.413>
actor = 'Nnarol'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2022-02-07.00:22:26.157>
creator = 'Nnarol'
dependencies = []
files = []
hgrepos = []
issue_num = 46671
keywords = ['patch']
message_count = 1.0
messages = ['412694']
nosy_count = 1.0
nosy_names = ['Nnarol']
pr_nums = ['31181']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46671'
versions = ['Python 3.11']

[Nnarol]

Incorrect error message by min_max(): "ValueError: min() arg is an empty sequence" when using the form

min(iterable, *[, default=obj, key=func]) -> value

and "iterable" is empty, like so:

    min([])

or:

    min(set())

"Sequence" is referred to, even though the function accepts any iterable. E.g. if a different type of collection, such as a set was provided by the user, "sequence" is still printed.

I propose to rephrase the error to "iterable argument is empty", to reflect actual behavior and be in line with the function's documented interface.

"arg" also does not name either any specific variable in C code or a parameter in user-facing documentation. Such an abbreviation is not used by the function's other error messages either, which simply write "argument" or "arguments" in free text, as appropriate in the given context.

Unlike for the error "max expected at least 1 argument, got 0", the above scenario's test does not include matching of the error string. This is probably the reason this was not noticed before. It would be nice to make the test more specific.

The issue seems trivial, but I am not familiar with the CPython project's policy on whether to treat messages of errors, printed on stderr as an interface, in which case, the change would be backwards-incompatible.
Definitely a decision to be made.

[SohamRatnaparkhi]

Hi, I want to solve this issue. How can I start? Thank you!