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 a390ebea17a96d1c93fc5f75b1e19916090a4561 by Hai Shi in branch 'main':
bpo-42035: Add a PyType_GetName() to get type's short name. (GH-23903)
https://github.com/python/cpython/commit/a390ebea17a96d1c93fc5f75b1e19916090a4561

> - 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 3e2c643ae0b21f9e596bfd9c8ec99ca546ea8d0f by Hai Shi in branch 'main':
bpo-42035: Add PyType_GetQualName() to get a type's qualified name. (GH-27551)
https://github.com/python/cpython/commit/3e2c643ae0b21f9e596bfd9c8ec99ca546ea8d0f

New changeset fcd651d16fc5ac3d07dd3f57f1001a861a2e7d23 by Hai Shi in branch 'main':
bpo-42035: Enhance test_get_type_name() of _testcapi (GH-27649)
https://github.com/python/cpython/commit/fcd651d16fc5ac3d07dd3f57f1001a861a2e7d23

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 :)