Petr Viktorin <encu...@gmail.com> added the comment:
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 PyType_Spec.name), and then expose the __name__/__module__ derived from it. It's not how CPython works, but that's OK for the limited API. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42035> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
