In the Limited API (where PyTypeObject is opaque), there is no way to retrieve the tp_name of a type object. The PyType_GetSlot() function doesn’t define a slot ID Py_tp_name. This makes it inconvenient to port existing code to the Limited API. Is this intentional? How to work around this?

The slots are originally intended for defining types (PyType_FromSpec); PyType_GetSlot is not as useful as it could be.
tp_name can be exposed, but it needs to also be handled properly PyType_FromSpec -- e.g. raise an error.

Ah, scratch that: PyType_GetSlot returns a function pointer.
To be correct, we should to expose a new function like PyType_GetName.

It's true that CPython currently doesn't always honor the distinction between data and function pointers, but the C standard says they're distinct, so it might bite us in the future.

True enough. Btw, PyType_FromSpec accepts Py_tp_doc (char *), Py_tp_base (PyTypeObject *), etc ... so to be strictly standard compliant, a union would be necessary.

PyType_GetName() sounds great.

One "proper" workaround at the moment is PyObject_GetAttrString(Py_TYPE(x), "__name__") and then process the result. This is somewhat "heavy" and strips the module name. "Py_tp_name" provides a convenient, exception safe, and backward compatible way to access tp_name.

What I actually do right now is to access the (opaque) PyTypeObject::tp_name by pointer offset. This certain defies the purpose of stable ABI!

Yes, for some cases the ship has sailed. I don't think we can add unions now -- the stable ABI needs to be stable.

I'll be happy to review adding a PyType_GetName function.

Now that I see the implementation (and now that I'm spending a lot of time trying to formalize what is good stable API), I see a problem with PyType_GetName: it effectively returns a borrowed reference.
The proposed docs say:

Callers can hold [the retuned] pointer until the type has been deallocated.

This is not friendly to alternate Python implementations. For example, if tp_name is stored as UTF-32, it would need to generate the char* data -- and then retain it until the class is deallocated.
I guess the "correct" way would be to return a Py_buffer, which would (in CPython) reference the class.

Victor, what do you think?

New C API functions must not return borrowed references, but strong references.

A type has different names:

• short name: "name"
• qualified name: "module.name"

Which one should be returned by PyType_GetName()? Is there a warranty that it's always short or always qualified?

New C API functions must not return borrowed references, but strong references.

Thanks petr, victor for your suggestion. It's more friendly to users.

Which one should be returned by PyType_GetName()? Is there a warranty that it's always short or always qualified?

Returning short or qualified name depends on how to define the tp_name in PyType_Spec or type object. IMHO, PyType_GetName() return the original defined type name is fine to users.

Wait. petr mentioned _PyType_Name in PR 23903 which use the short name. So I am not sure which way is better. Lol~

I found type.__name__ has the implementation details in https://github.com/python/cpython/blob/master/Objects/typeobject.c#L486.
IMHO, keep the consistency in PyType_GetName() is OK.

Victor, Petr. Do you think it make senses?

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.

• there is still no way to get t.tp_name
  Can we create PyType_GetDataSlot function to return the data pointer?

If we go this way, why not add PyType_GetQualName as well?
+1. I will create another PR after PR-23903 merged.

Can we create PyType_GetDataSlot function to return the data pointer?

No, see the borrowed pointer issues above.

I will create another PR after PR-23903 merged.

Great, thank you!

New changeset a390ebe by Hai Shi in branch 'main':
bpo-42035: Add a PyType_GetName() to get type's short name. (GH-23903)
a390ebe

• for the qualified name you can use PyObject_GetAttrString(t, "__qualname__")

After PR-27551 merged, we can use PyType_GetQualName() to get type's __qualname__.

PyType_GetName() is a nice addition, thanks.

New changeset 3e2c643 by Hai Shi in branch 'main':
bpo-42035: Add PyType_GetQualName() to get a type's qualified name. (GH-27551)
3e2c643

New changeset fcd651d by Hai Shi in branch 'main':
bpo-42035: Enhance test_get_type_name() of _testcapi (GH-27649)
fcd651d

Now, I wonder if we should also introduce PyType_GetModuleName for __module__, or stop and close this as fixed.

Now, I wonder if we should also introduce PyType_GetModuleName for __module__, or stop and close this as fixed.

IMO, I suggest to close this bpo. We can get the tp_name by the C API now. If there have user want get __module__, we can open a new bpo to discuss :)