Thos are great idea. I love the current trend of trying to give better error messages. Another pet peave of mine: TypeError not providing at least 'raiser' 'accepted type', 'given value' and 'given value type'. E.G, int() does an ok job: >>> int(foo) ValueError: invalid literal for int() with base 10: '1O' raiser: int() accept type: a base 10 literal value given: 1O But it could be improved by givin the type of the give value. Indeed in that case, I got a string composed of one and the letter O, but looks like the number 10. Some students can struggle with those. list, set and tuple less not as good: >>> tuple(foo) TypeError: 'int' object is not iterable No raiser, no value given. It's hard to find out what's the problem is. The biggest issue here is that if you have a long line with tuple() in the middle, yuou need to know the problem comes from tuple. Another problem is that many people don't know what iterable means. A better error message would be: TypeError: tuple() only accept iterables (any object you can use a for loop on). But it received '1', which is of type <int>. Some things deserve a big explanation to solve the problem. It would be nice to add a link to official tutorial in the documentation. E.G, encoding is a big one: In [8]: b'é' + 'é' File "<ipython-input-8-cfac1add5f26>", line 1 b'é' + 'é' ^ SyntaxError: bytes can only contain ASCII literal characters. This is not helpful to somebody unaware of the difference between text and bytes. Possible solution: In [8]: b'é' + 'é' File "<ipython-input-8-cfac1add5f26>", line 1 b'é' + 'é' ^ SyntaxError: You cannnot concatenate bytes (b'é...') with a string ('é...'). Learn more about fixing this error at https://doc.python.org/errors/7897978 Of course, the repr will often need to be shorten but a short repr is better than none. Should we make a PEP with all of those ? Le 25/10/2016 à 09:23, Neil Girdhar a écrit :
Also, for something like this:
In [1]: class A: ...: pass ...:
In [2]: A(x=2) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-2-857108bff989> in <module>() ----> 1 A(x=2)
TypeError: object() takes no parameters
It would be nice to say TypeError: object() takes no parameters, but keyword argument "x" given. I understand that the value of "x" might not have a __repr__ method, but the key name has to be string, so this should be easily doable at least for extra keyword arguments? For positional arguments, maybe just print how many were passed to object? Knowing the key name would have helped me with debugging. Usually, I print(kwargs) somewhere up the inheritance chain and run my program again.
On Tuesday, October 25, 2016 at 3:19:57 AM UTC-4, Neil Girdhar wrote:
I was thinking of posting something like the first suggestion myself. Both would be a great additions.
On Monday, October 24, 2016 at 6:10:52 PM UTC-4, Ryan Gonzalez wrote:
I personally find it kind of annoying when you have code like this:
x = A(1, B(2, 3))
and Python's error message looks like this:
TypeError: __init__() takes 1 positional argument but 2 were given
It doesn't give much of a clue to which `__init__` is being called. At all.
The idea: when showing the function name in an error like this, show the fully qualified name, like:
TypeError: A.__init__() takes 1 positional argument but 2 were given
This would be MUCH more helpful!
Another related change would be to do the same thing in tracebacks:
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in __init__ AssertionError
to:
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 2, in MyClass.__init__ AssertionError
which could make it easier to find where exactly an error originated.
-- Ryan (ライアン) [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/