8000 gh-121654: Add PyType_Freeze() function by vstinner · Pull Request #122457 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

gh-121654: Add PyType_Freeze() function #122457

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.

Sign up for GitHub

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

Merged
merged 11 commits into from
Oct 25, 2024
Merged

gh-121654: Add PyType_Freeze() function #122457

Changes from 1 commit
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
2d24aba
gh-121654: Add PyType_Freeze() function
vstinner Jul 30, 2024
f7bd310
Call PyType_Modified()
vstinner Aug 1, 2024
f7d75ac
Fix typo
vstinner Aug 1, 2024
1fcda68
Add more elaborate test on MRO
vstinner Aug 2, 2024
beea5e3
Check __mro__ instead of __bases__
vstinner Aug 26, 2024
0155362
Update Doc/c-api/type.rst
vstinner Aug 27, 2024
1c1fa7e
Update Lib/test/test_capi/test_type.py
vstinner Aug 27, 2024
e0cc4be
Type must not be used before made immutable
vstinner Sep 23, 2024
a9f1f01
Merge branch 'main' into type_freeze
vstinner Sep 30, 2024
0f98b64
Merge branch 'main' into type_freeze
vstinner Oct 16, 2024
2752daa
Test the error message
vstinner Oct 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Check __mro__ instead of __bases__
  • Loading branch information
@vstinner
vstinner committed Aug 26, 2024
commit beea5e39219e5df4e4483a4aeb06b0f4c17dafc5
24 changes: 19 additions & 5 deletions Objects/typeobject.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4643,9 +4643,14 @@ check_basicsize_includes_size_and_offsets(PyTypeObject* type)
}

static int
check_immutable_bases(const char *type_name, PyObject *bases)
check_immutable_bases(const char *type_name, PyObject *bases, int skip_first)
{
for (Py_ssize_t i=0; i<PyTuple_GET_SIZE(bases); i++) {
Py_ssize_t i = 0;
if (skip_first) {
// When testing the MRO, skip the type itself
i = 1;
}
for (; i<PyTuple_GET_SIZE(bases); i++) {
PyTypeObject *b = (PyTypeObject*)PyTuple_GET_ITEM(bases, i);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the necro-posting.
IIUC only improperly constructed tuples can store NULL items. Is this such a case? If so, is the following check redundant?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, I just moved the code. The test was already there before.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, thanks!

if (!b) {
return -1;
Expand Down Expand Up @@ -4818,7 +4823,7 @@ _PyType_FromMetaclass_impl(
* and only heap types can be mutable.)
*/
if (spec->flags & Py_TPFLAGS_IMMUTABLETYPE) {
if (check_immutable_bases(spec->name, bases) < 0) {
if (check_immutable_bases(spec->name, bases, 0) < 0) {
goto finally;
}
}
Expand Down Expand Up @@ -11190,8 +11195,17 @@ add_operators(PyTypeObject *type, PyTypeObject *def)
int
PyType_Freeze(PyTypeObject *type)
{
PyObject *bases = type->tp_bases;
if (check_immutable_bases(type->tp_name, bases) < 0) {
// gh-121654: Check the __mro__ instead of __bases__
PyObject *mro = type_get_mro(type, NULL);
if (!PyTuple_Check(mro)) {
Py_DECREF(mro);
PyErr_SetString(PyExc_TypeError, "unable to get the type MRO");
return -1;
}
Comment on lines +11342 to +11346
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How difficult to add test for this case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that it's possible to create a type with a MRO which is not a tuple. Using a metaclass, it's possible to override the MRO, but internally, Python converts mro() result into a tuple.

I added this check since type_get_mro() returns None if type->tp_mro is NULL. But I have no idea how to create a type with type->tp_mro=NULL. It's more a sanity check.


int check = check_immutable_bases(type->tp_name, mro, 1);
Py_DECREF(mro);
if (check < 0) {
return -1;
}

Expand Down
Loading
0