New submission from Karthikeyan Singaravelan <tir.kar...@gmail.com>:
Python 3 supports type annotations in functions but when there is a TypeError due to calling a function then only the arguments are given in the error message. If the function has type annotations then adding them to the error message will give better experience and context. This doesn't break any existing code without type annotations but improves errors for code that has type annotations giving a better error reporting experience. Currently format_missing method one of the methods used to raise TypeError that returns the name of the required positional arguments. The function receives the code object and type annotations are present in the function object. Hence I have used the code_object->co_name to get the function object from globals. After getting the function object I go through the annotations if present to form an error message to be attached with the existing error message. I have implemented it in my branch : https://github.com/tirkarthi/cpython/tree/error-message-annotations # foo_signature.py from typing import List, Dict, NoReturn def get_profile_a(user_id: int, likes: Dict[str, int]) -> Dict[str, int]: return {'user_id': user_id, 'likes': len(likes.keys())} if __name__ == "__main__": get_profile_a() # Error message for functions without type hints patch cpython git:(master) ✗ ./python foo_signature.py Traceback (most recent call last): File "foo_signature.py", line 11, in <module> get_profile_a() TypeError: get_profile_a() missing 2 required positional arguments: 'user_id' and 'likes' # Error message for functions with type hints patch in my branch cpython git:(error-message-annotations) ✗ ./python foo_signature.py Traceback (most recent call last): File "foo_signature.py", line 11, in <module> get_profile_a() TypeError: get_profile_a() missing 2 required positional arguments: 'user_id' and 'likes' Annotation: (user_id: <class 'int'>, likes: typing.Dict[str, int], return: typing.Dict[str, int]) The proposed patch adds the annotations in the end thus giving more context to the user. Pros : * Better error reporting and more context that helps beginners like Elm/Rust that have improved error messages. * This will also motivate developers to write type annotations since error messages become more useful. Cons : * Since code_object is present in the call site where TypeError is raised I need to do a lookup of the globals to get the function object. This can be fixed in the way get_type_hints works on a function object. This also blocks me from writing tests where the function is defined inside a class that inherits from unittest.TestCase. * After getting the annotations I need to form a string with the relevant parameters. Since most of them are hash lookups I don't think there is a cost involved here. Most of the time TypeError is raised to the user. My C skills are also low and I hope code can be improved much better here. I am good with the core team rejecting this patch but just wanted to put forward the idea. I have also created a thread in python-ideas mailing list to gather feedback about this and hope it gains some traction. I received good feedback from Ethan Smith, mypy core developer on Reddit : https://www.reddit.com/r/Python/comments/92eh1g/type_annotations_in_error_messages_for_better/e3655z1/ python-ideas thread : https://mail.python.org/pipermail/python-ideas/2018-July/052463.html I am adding Raymond and Terry since the previous PRs I have raised regarding error messages were reviewed by them. Also from the past discussions they make decisions on whether the change and it's effect is worth enough to be added to the core given the implementation complexity. Feel free to un-assign yourself if this is irrelevant. Thanks ---------- components: Interpreter Core messages: 322527 nosy: rhettinger, terry.reedy, xtreak priority: normal severity: normal status: open title: Include type annotations in error messages for better errors type: enhancement versions: Python 3.8 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue34254> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
