-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
Remove Py_TPFLAGS_HAVE_VERSION_TAG flag? #86913
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
Comments
Since the PyTypeObject structure is excluded from the limited C API and the stable ABI on purpose (PEP-384), I don't see the purpose of the Py_TPFLAGS_HAVE_VERSION_TAG flag. Moreover, a new flag was added recently: #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x030A0000
/* Type has am_send entry in tp_as_async slot */
#define Py_TPFLAGS_HAVE_AM_SEND (1UL << 21)
#endif Should it be also removed? For example, Py_TPFLAGS_HAVE_FINALIZE was deprecated in bpo-32388 by: commit ada319b
n tp_flags.
By the way, is it worth it to remove Py_TPFLAGS_HAVE_FINALIZE? Or is it going to break too many extension modules? |
Let's emit the deprecated message if Py_TPFLAGS_HAVE_VERSION_TAG is set ;) |
Maybe we can keep the constants but define them as 0 and deprecate them. The question is more if these constants solve a real ABI issue or not. |
IMO, There have no more exact description of
I am not found who use Py_TPFLAGS_HAVE_AM_SEND or Py_TPFLAGS_HAVE_FINALIZE in github.I perfer to keep it as soon as posssible if there have users using them. |
IMO, these flags are useless. Both the stable ABI and the version-specific builds of extension modules use the memory layout of the current interpreter and fill unset slots with NULL. Py_TPFLAGS_HAVE_AM_SEND is new in 3.10, so it can be removed (or replaced by a check for Py_TYPE(iter)->tp_as_async != NULL && Py_TYPE(iter)->tp_as_async->am_send != NULL). Py_TPFLAGS_HAVE_VERSION_TAG and Py_TPFLAGS_HAVE_FINALIZE are there since 2.6 and 3.8 respectively, and mentioned in documentation. Extensions that use the stable ABI can *check for them*. We cannot do a survey of all existing extension modules. The flags can't be removed without breaking stable ABI. |
I don't think that it was right thing to break binary compatibility. It virtually buried the stable ABI. |
Serhiy Storchaka:
IMO there is a misunderstanding about the stable ABI. PyType_FromSpec() doesn't need Py_TPFLAGS_HAVE_xxx flags: this function allocates a heap type which *has* all these members (set to 0/NULL by default). And it's not possible to define a static type using the limited C API, since the PyTypeObject structure is excluded from it on purpose. See bpo-32388 for a similar discussion. |
Ah, I see that there is a misunderstanding. The flag is used for two things: (*) Create/Declare a type IMO Py_TPFLAGS_HAVE_VERSION_TAG and Py_TPFLAGS_HAVE_FINALIZE are useless for that. (*) Check if a type has the flag An extension built with the stable ABI *can* use PyType_HasFeature(type, Py_TPFLAGS_HAVE_VERSION_TAG). I'm only aware of PyQt which uses the stable ABI. Is there other projects using it? Do these projects check for Py_TPFLAGS_HAVE_VERSION_TAG or Py_TPFLAGS_HAVE_FINALIZE flag? If we cannot be used that no extension module built with the stable ABI for these flags, the safe option is to keep them, deprecate them, and always define them. For example, add the flags to Py_TPFLAGS_DEFAULT and/or add them in type_new() or PyType_Ready(). -- Py_TPFLAGS_HAVE_VERSION_TAG is really an internal tag. It should only be used by _PyType_Lookup(). I'm not sure why someone would like to check explicitly for the Py_TPFLAGS_HAVE_FINALIZE flag. I would expect that only Python internals call the tp_finalize slot. |
I think there are. Who knows how many; they're not required to register anywhere. If the flags do end up being removed, it would be nice to reserve the bits (in a comment), so they aren't reused too soon. Also, ISTM that PEP-387 applies, and requires warning for two releases. How can that be done for flags? |
The bit cannot be repurposed, since older extensions using the stable ABI might set it. |
Is there anything left in this issue? |
I usually wait until buildbots are green before closing the bpo, but I don't think there's anything else. |
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: