This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author xtreak
Recipients rhettinger, terry.reedy, xtreak
Date 2018-07-28.07:48:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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 :


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__":

# Error message for functions without type hints patch

cpython git:(master) ✗ ./python
Traceback (most recent call last):
  File "", line 11, in <module>
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
Traceback (most recent call last):
  File "", line 11, in <module>
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 :

python-ideas thread :

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.

Date User Action Args
2018-07-28 07:48:33xtreaksetrecipients: + xtreak, rhettinger, terry.reedy
2018-07-28 07:48:32xtreaksetmessageid: <>
2018-07-28 07:48:32xtreaklinkissue34254 messages
2018-07-28 07:48:32xtreakcreate