Improve UX by using fully-qualified name in some `TypeError`

[smurfix]

Feature or enhancement

Proposal:

The error message TypeError: Can't instantiate abstract class FOO without an implementation for abstract methods 'BAR' doesn't tell me with module FOO comes from.

This is unfortunate, particularly in larger code bases where several FOO-ish classes live in distinct modules but have the same local name: discovering which class triggered the problem may require nontrivial code analysis.

Thus I propose to extend this error message so that it reports the module name, i.e. abstract class BAZ.BAR.FOO, instead.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[picnixz]

AFAICT, if the module name is not set for the class, it's because it's not created yet. The message is the following (in Obejcts/typeobject.c)

        PyErr_Format(PyExc_TypeError,
                     "Can't instantiate abstract class %s "
                     "without an implementation for abstract method%s '%U'",
                     type->tp_name,
                     method_count > 1 ? "s" : "",
                     joined);

However, type->tp_name should include the name of the module. If it doesn't, it's not accessible at this location.

[smurfix]

@picnixz I don't think that's correct. In my case it's a typical class with no special characteristics (except that it can't be instantiated due to an abstract method).

    ... try:
    ...     return self.cls_RepoInfo(self, repo)
    ... except TypeError:
    ...     breakpoint()

| TypeError: Can't instantiate abstract class RepoInfo without an implementation for abstract methods 'create', 'load_'
(Pdb) p self.cls_RepoInfo
<class 'moat.src.api.radicle.RepoInfo'>

So if pdb can easily get at the qualified name at that point, so should the code that generates the exception.

[picnixz]

Well, I don't really know why it doesn't include the fully-qualified name. Just that the error is using bare type->tp_name which is documented as being <module>.<name>. The difference between PDB here and the interpreter is that PDB is using repr(the_type) which includes the module information because it looks up __module__.

We could run the same logic for formatting the exception but that's not the only place. I would however be in favor but we need to only extract part of what type_repr does.

[smurfix]

Mmh. It may be documented to include the module name, but (at least for Python-defined class types) it clearly does not.

[picnixz]

Yes, that's why I said "we could use the repr". What I meant is that repr does more work which is why when you write p my_class you get more information. It's the same as doing print(repr(my_class)) or print(my_class). Note that type.__repr__ also handles the fact when tp_name contains a dot, but I think it's only for classes implemented in C (namely, those that set their tp_name).

I think we can make a small utility function in typeobject.c which gets <module>.<name> when possible, either by directly using tp_name or by relying on the same logic as type.__repr__.

[skv0zsneg]

Hi everyone! Can I take this issue?