GH-90699: Intern statically allocated strings

[kumaraditya303]

This is similar to how strings are interned for deepfreeze.

• Issue: Replace _Py_IDENTIFIER() with statically initialized objects. #90699

Automerge-Triggered-By: GH:ericsnowcurrently

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @kumaraditya303 for commit f0e01c4 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

[AA-Turner]

Should pycore_runtime_init.h be marked as generated?

cpython/.gitattributes

Lines 69 to 71 in 243ed54

	Include/internal/pycore_ast.h generated
	Include/internal/pycore_ast_state.h generated
	Include/internal/pycore_opcode.h generated

A

[kumaraditya303]

Should pycore_runtime_init.h be marked as generated?

That file also contains handwritten struct initialization macros so I don't think so.

[ericsnowcurrently]

That file also contains handwritten struct initialization macros so I don't think so.

Yeah, only _Py_global_objects_INIT is generated and we want changes to the rest to get expanded by default in PRs.

I suppose we could separate the generated part from the rest, AKA pycore_global_objects_init.h (or even _pycore_global_objects_init.h). I doubt that would be a problem, especially if it makes occasional PRs a little easier to review (e.g. no ambiguity about what is generated and what itsn't).

[ericsnowcurrently]

Would we also move the generated parts of pycore_global_strings.h to a separate header file (for the same reasons)?

[AA-Turner]

With this PR, ~93% of the lines in pycore_runtime_init.h are autogenerated -- I did miss that it starts with ~120 lines of handwritten code, but for future maintenence / ease of review I'd agree with Eric that it might be better to move to its own file. (A large part is also my unfamiliarity with this part of the code, to be fair -- if it causes more hassle than it's worth then the status quo wins).

A

[kumaraditya303]

I can work on a PR to separate the generated and handwritten code but it will be a separate PR. I have other changes enqueued for static strings which depend on this PR so I want to get this in first.

[kumaraditya303]

@ericsnowcurrently FYI, I have created #94051 to separate generated code.

[gvanrossum]

I'm hoping Eric can do the review here.

[ericsnowcurrently]

This mostly looks good. I just have a few comments.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[ericsnowcurrently]

Thanks for make those updates! This is just about ready. I'll approve and merge it once you've merged in the gh-94051 changes.

[ericsnowcurrently]

LGTM

[ericsnowcurrently]

Thanks for working on this, @kumaraditya303!

[kumaraditya303]

Thanks for working on this

Thanks for the reviews!