[Python-Dev] bpo-34595: How to format a type name? (original) (raw)

Neil Schemenauer nas-python at arctrix.com
Fri Sep 14 01:47:53 EDT 2018


On 2018-09-13, Victor Stinner wrote:

Right, that's a side effect of the discussion on the C API. It seems like PyTYPE() has to go in the new C API. Sorry, the rationale is not written down yet, but Dino convinced me that PyTYPE() 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.



More information about the Python-Dev mailing list