Hmm, I'm not able to reproduce that failure locally.

The commit title doesn't match what I see in the PR -- how come all these extra ids were added? Were they somehow lost in the offending PR (GH-31261)? I don't see how.

All the added ids are the ones used in the frozen modules. They should have been added in that PR (from running make regen-global-objects). There is a CI check that should have caught this and blocked the PR. I'll have to see why it didn't.

...or it may be something else and I was wrong and Kumar's PR is fine. It isn't clear yet. I'm checking.

Yeah, I compared an old and the new deepfreeze.c output (on Windows) and while there were some differences but not in lines with Py_ID in them. So then the question is where do all these new identifiers come from.

(Those extra identifiers, like "a", definitely exist in the deep-frozen code. But they don't exist in the hand-picked lists in generate_global_objects.py. Maybe you have some script that automates the hand-picking that would up date generate_global_objects.py, and somehow you ran that script but didn't commit the output? That would be consistent with the test failure in CI.

Yeah, it was my fault. Some changes where I was using Py_ID() in argument clinic (in a different branch) somehow were still around when I ran generate_global_objects.py. make clean took care of it for me.

Sorry for the noise.