Skip to content
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

gh-84436: Add codemod for _PyVarObject_HEAD_IMMORTAL_INIT #103308

Closed

Conversation

eduardo-elizondo
Copy link
Contributor

@eduardo-elizondo eduardo-elizondo commented Apr 6, 2023

This extends the main PR19474 by running the codemod to replace all internal uses of PyVarObject_HEAD_INIT for _PyVarObject_HEAD_IMMORTAL_INIT to be able to initialize them as immortal instances.

The reason this was separated out was to provide a cleaner PR to review the main changes of immortal instances in PR19474. While this one is mostly the codemoded files. Created this as direct feedback from: #19474 (comment)

@eduardo-elizondo eduardo-elizondo changed the title gh-84436: Implement _PyObject_HEAD_IMMORTAL_INIT and _PyVarObject_HEAD_IMMORTAL… gh-84436: Add codemod for _PyVarObject_HEAD_IMMORTAL_INIT Apr 6, 2023
@arhadthedev arhadthedev added interpreter-core (Objects, Python, Grammar, and Parser dirs) extension-modules C modules in the Modules dir labels Apr 6, 2023
Copy link
Member

I assume someone is going to review each of these to determine whether they're in the right places? (e.g. the public docs should not be using an internal macro)

If we really do want to update every single use, well, that's why we have the original macro. We should just change it.

My understanding of immortal objects is that we'd carefully opt-in certain types, and not do a global find/replace like this. But possibly the design has changed in a way I haven't kept up with.

At the very least, if it belongs in public docs, make it a public macro. And if it applies literally everywhere, just modify the existing macro.

@@ -0,0 +1,3 @@
Replace all internal uses of PyVarObject_HEAD_INIT fo
_PyVarObject_HEAD_IMMORTAL_INIT to be able to initialize them as immortal
objects since they live thorughout the entire execution
Copy link
Member

Choose a reason for hiding this comment

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

Typo

Suggested change
objects since they live thorughout the entire execution
objects since they live throughout the entire execution

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

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

Like Steve, I do wonder, why not change the macro instead of 150+ files?

If the macro needs to remain different, could we define the macro different when Py_BUILD_CORE is set?

@rhettinger rhettinger removed their request for review April 6, 2023 18:23
@eduardo-elizondo
Copy link
Contributor Author

eduardo-elizondo commented Apr 8, 2023

carefully opt-in certain types, and not do a global find/replace like this

@zooba We are opting in all static objects as they live throughout the entire execution of the runtime!

@eduardo-elizondo
Copy link
Contributor Author

eduardo-elizondo commented Apr 8, 2023

Like Steve, I do wonder, why not change the macro instead of 150+ files?

@zooba @gvanrossum the main goal was to not change the expectations of the public C-API of PyObject_HEAD_INIT and PyVarObject_HEAD_INIT. I think that it should use the immortal value by default but given that this is a public C-API, the goal was to minimize the number of 'disruptive' changes (though it should still be compatible backwards compatible).

All that said, the solution of using Py_BUILD_CORE works really nicely so I'll incorporate that in the main PR and close this PR. Whether we change the default to be immortal or not, I'll leave that to a future discussion (unless anyone has strong opinions otherwise 🙂 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting review extension-modules C modules in the Modules dir interpreter-core (Objects, Python, Grammar, and Parser dirs)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants