This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author petr.viktorin
Recipients corona10, fancitron, petr.viktorin, shihai1991, vstinner
Date 2021-07-27.11:44:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Sorry for the delay; getting 652 into Python 3.10 took up most of my time.

So, in the current proposal:
- `PyType_GetName(t)` is equivalent to `PyObject_GetAttrString(t, "__name__")`
- for the qualified name you can use `PyObject_GetAttrString(t, "__qualname__")`
- there is still no way to get t.tp_name

The advantage of PyType_GetName over a regular getattr is that it's fast for heap types (there's no dict lookup, and the string object is cached as ht_name). For static types, it's a bit slower (a string object needs to be built, but still there's no dict lookup).

If we go this way, why not add PyType_GetQualName as well?

(Is the speed, compared to getattr, worth adding two new functions? I guess it is, barely.)


The OP specifically requested a way to get tp_name, which the current PR does not do. I don't think it should, either:
- there's no way to assure that `char* tp_name` is not deallocated before the caller is done with it (especially considering that other Python implementations should be able to implement the stable ABI, and those shouldn't need store tp_name as char*).
- there is already __name__ and __qualname__ (and __module__); tp_name is a weird mix that I, personally, won't miss if it goes away. I think it's OK to only use it for creation (as, and then expose the __name__/__module__ derived from it. It's not how CPython works, but that's OK for the limited API.
Date User Action Args
2021-07-27 11:44:53petr.viktorinsetrecipients: + petr.viktorin, vstinner, corona10, shihai1991, fancitron
2021-07-27 11:44:53petr.viktorinsetmessageid: <>
2021-07-27 11:44:53petr.viktorinlinkissue42035 messages
2021-07-27 11:44:53petr.viktorincreate