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

Improve error reporting for the argument parsing C API #47604

Open
Cito mannequin opened this issue Jul 14, 2008 · 9 comments
Open

Improve error reporting for the argument parsing C API #47604

Cito mannequin opened this issue Jul 14, 2008 · 9 comments
Labels
3.13 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-C-API type-feature A feature request or enhancement

Comments

@Cito
Copy link
Mannequin

Cito mannequin commented Jul 14, 2008

BPO 3354
Nosy @rhettinger, @ronaldoussoren, @Cito, @larryhastings, @benjaminp, @iritkatriel

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 2008-07-14.12:53:23.426>
labels = ['interpreter-core', 'expert-C-API', 'type-feature', '3.11']
title = 'Improve error reporting for the argument parsing C API'
updated_at = <Date 2021-11-29.16:50:41.251>
user = 'https://github.com/Cito'

bugs.python.org fields:

activity = <Date 2021-11-29.16:50:41.251>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core', 'C API']
creation = <Date 2008-07-14.12:53:23.426>
creator = 'cito'
dependencies = []
files = []
hgrepos = []
issue_num = 3354
keywords = []
message_count = 9.0
messages = ['69651', '69653', '69657', '69658', '69659', '69662', '69669', '191584', '407295']
nosy_count = 8.0
nosy_names = ['rhettinger', 'ronaldoussoren', 'cito', 'larry', 'benjamin.peterson', 'mishok13', 'Ankur.Ankan', 'iritkatriel']
pr_nums = []
priority = 'low'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue3354'
versions = ['Python 3.11']

@Cito
Copy link
Mannequin Author

Cito mannequin commented Jul 14, 2008

When you sort a list with list.sort() or sorted(list), and set the
reverse parameter to None, then you get the following misleading error
message:

TypeError: an integer is required

I would expect a more proper error message for the reverse parameter,
such as "reverse must be a boolean", and maybe reverse=None also
accepted as default value, i.e. False.

@Cito Cito mannequin added type-bug An unexpected behavior, bug, or error interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Jul 14, 2008
@benjaminp
Copy link
Contributor

Well, booleans technically are integers.

@Cito
Copy link
Mannequin Author

Cito mannequin commented Jul 14, 2008

The problem is not only that the error message "TypeError: an integer is
required" has "integer" instead of "boolean", but it does not mention
the attribute name "reverse", i.e. it does not even say *where* the
integer is required. I firmly believe error messages should not only be
technically correct, but also precise, meaningful and helpful for the user.

@benjaminp
Copy link
Contributor

Patches are welcome.

@benjaminp benjaminp reopened this Jul 14, 2008
@Cito
Copy link
Mannequin Author

Cito mannequin commented Jul 14, 2008

The unspecific error message is thrown by the vgetargskeywords()
function, so changing this behavior would be a larger, more difficult
and general issue (similar to bpo-1283289). We could go another path and
require an object for 'reverse' instead of an integer in the format
parameter, and then do our own checks and error messages on 'reverse'.
This looks reasonable if we want to change the behavior anyway, so that
reverse=None is accepted (cmp=None and key=None are also accepted), or
even an implicit bool(reverse) is used (but this could hide possible
errors). If we want to keep the behavior and only fix the error message,
then a more general fix of vgetargskeywords() seems to be the proper
solution.

@rhettinger
Copy link
Contributor

I think this is closer to a language wide change and should probably be
addressed for 2.7 and 3.1. It would be great to change the C argument
parsing API to make its error messages more specific.

For Py2.6, I think things are fine as it stands. This isn't a bug
(tests pass, it matches results from previous pythons, etc)
Reclassifying as a feature request for improved error reports for the
argument parsing API.

@rhettinger rhettinger changed the title sort(reverse=None) prints misleading error message Improve error reporting for the argument parsing API Jul 14, 2008
@rhettinger rhettinger added type-feature A feature request or enhancement and removed type-bug An unexpected behavior, bug, or error labels Jul 14, 2008
@Cito
Copy link
Mannequin Author

Cito mannequin commented Jul 14, 2008

Agree. Seems to be a more general weakness of the argument parsing of
builtin functions and methods, that calls for a general solution instead
of a local patch. Luckily there are not so many cases where the errors
are misleading, since the builtin functions have very few and mostly
positioned parameters, so the problem is not as bad as it seems. There
may be only very few cases, like the example above, where the errors are
really too unspecific or misleading.

@merwok merwok changed the title Improve error reporting for the argument parsing API Improve error reporting for the argument parsing C API Feb 21, 2012
@ronaldoussoren
Copy link
Contributor

See also bpo-18269.

@iritkatriel
Copy link
Member

Reproduced in 3.11:

>>> sorted([1,2,3], reverse=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object cannot be interpreted as an integer

@iritkatriel iritkatriel added the 3.11 only security fixes label Nov 29, 2021
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@iritkatriel iritkatriel added 3.12 bugs and security fixes and removed 3.11 only security fixes labels Oct 5, 2022
@iritkatriel iritkatriel added 3.13 new features, bugs and security fixes and removed 3.12 bugs and security fixes labels May 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) topic-C-API type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

5 participants