Message398292
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. |
|
Date |
User |
Action |
Args |
2021-07-27 11:44:53 | petr.viktorin | set | recipients:
+ petr.viktorin, vstinner, corona10, shihai1991, fancitron |
2021-07-27 11:44:53 | petr.viktorin | set | messageid: <1627386293.4.0.126960925692.issue42035@roundup.psfhosted.org> |
2021-07-27 11:44:53 | petr.viktorin | link | issue42035 messages |
2021-07-27 11:44:53 | petr.viktorin | create | |
|