Steven D'Aprano <steve+pyt...@pearwood.info> added the comment:
On Sun, Jan 05, 2020 at 10:32:26PM +0000, Ram Rachum wrote:
[...]
> TypeError: __init__() takes 2 positional arguments but 3 were given
>
> As you can see, it's pretty simple to get this exception text, so I'm not
> sure why you didn't get that text.
But I *did* get that text. I'm asking how you got the *different* text
which you gave in your initial request.
Firstly, you stated that you got the fully-qualified exception type:
builtins.TypeError
rather than just TypeError, which was my question. How did you get the
fully-qualified exception class?
Secondly you quoted the error message:
__init__() takes 1 positional argument but 2 were given
which is what I get in 3.5 using `def __init__(self)`, but in 3.8 it
gives a different message "MyClass() takes no arguments".
I'm not worried about the error message discrepency, since that's
irrelevant to your enhancement request, and easily explained if you were
quoting from an older version of Python. But I don't know how you got
the `builtins.TypeError` fully-qualified part. That is the part I'm
asking about.
> Regarding you saying it's more annoying than useful: Especially for
> methods such as `__init__`, it's often difficult to understand which
> class is being instantiated, especially in a complex codebase.
I agree with you that there are occasions where this could be difficult.
Apart from the "no source code" case, I can see that might be the case
if the failing line is a complex expression like this:
do_things(Spam(arg)[Eggs(None)] + Cheese(Aardvark(thingy)))
and you don't know which of Spam, Eggs, Cheese or Aardvark has failed.
Or in an expression like this:
lookup_class['some key'](arg)
where the source is only an indirect reference to the class you want.
But in my experience, the great bulk of calls to classes (apart from
simple "atomic" values like int, float, str, etc) stand alone:
obj = MyClass(arg)
and there is no difficulty in telling which class has the problem.
In my experience, I would say > 90% easy cases and < 10% tricky cases.
(YMMV.)
So in my opinion, and I recognise that you may disagree, this is only of
benefit in a minority of cases. For the majority of cases, it will only
be additional noise in the message that adds nothing that wasn't already
obvious from the source line.
And in particular, beginners are often intimidated by error messages,
and the longer the error message, the more they are intimidated. In that
case, `TypeError: __init__ ...` is shorter and therefore less scary than
`builtins.TypeError: package.some_module.MyClass.__init__ ...`.
So I'm not disputing that this will be useful *sometimes*. I'm just
trying to weigh up the cons of longer, more complex error messages
with redundant information versus the occasional cases where the
information is helpful.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue39212>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
