[Python-Dev] bpo-34595: How to format a type name?

[Neil Schemenauer]

On 2018-09-13, Victor Stinner wrote:
> Right, that's a side effect of the discussion on the C API. It seems
> like Py_TYPE() has to go in the new C API. Sorry, the rationale is not
> written down yet, but Dino convinced me that Py_TYPE() has to go :-)

My understanding is that using Py_TYPE() inside the CPython
internals is okay (i.e. using a borrowed reference).  However,
extension modules would preferrably not use APIs that give back
borrowed references.  A clean API redesign would remove all of
those.

So, what are extension modules supposed to do?  We want to give them
an easy to use API.  If we give them %t that takes an object and
internally does the Py_TYPE() call, they have a simple way to do the
right thing.

E.g.

             PyErr_Format(PyExc_TypeError,
                 "\"%s\" must be string, not %.200s", name,
                 src->ob_type->tp_name);

becomes

             PyErr_Format(PyExc_TypeError,
                 "\"%s\" must be string, not %t", name, src);

This kind of code occurs often in extension modules.  If you make
them get a strong reference to the type, they have to remember to
decref it.  It's not a huge deal but is a bit harder to use.  I like
the proposal to provide both %t and %T.  Our format code is a bit
more complicated but many extension modules get a bit simpler.
That's a win, IMHO.

For the Python side, I don't think you need the % format codes.  You
need a idiomatic way of getting the type name.  repr() and str() of
the type object is not it.  I don't think changing them at this
point is a good idea.  So, having a new property would seem the
obvious solution.  E.g.

     f'"{name}" must be string, not {src.__class__.__qualname__}'

That __qualname__ property will be useful for other things, not just
building type error messages.