-
-
Notifications
You must be signed in to change notification settings - Fork 31.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[C API] PyType_GetSlot cannot get tp_name #86201
Comments
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. |
Ah, scratch that: PyType_GetSlot returns a function pointer. 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. 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. Victor, what do you think? |
New C API functions must not return borrowed references, but strong references. |
A type has different names:
Which one should be returned by PyType_GetName()? Is there a warranty that it's always short or always qualified? |
Thanks petr, victor for your suggestion. It's more friendly to users.
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 |
I found 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:
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:
|
|
No, see the borrowed pointer issues above.
Great, thank you! |
After PR-27551 merged, we can use PyType_GetQualName() to get type's |
PyType_GetName() is a nice addition, thanks. |
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 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: