[Python-ideas] Showing qualified names when a function call fails

[Michel Desmoulin]

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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>