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.