bpo-46712: Let generate_global_objects.py Run on Earlier Python Versions

[ericsnowcurrently]

https://bugs.python.org/issue46712

[ericsnowcurrently]

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

[gvanrossum]

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.

[ericsnowcurrently]

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.

[gvanrossum]

Ah, I see. Perhaps this wasn't caught because I simplified some things in the freeze_modules.py script. (Or if it looks Kumar did so, it was my idea. :-)

[ericsnowcurrently]

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

[gvanrossum]

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.

[gvanrossum]

(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.

[ericsnowcurrently]

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.

[ericsnowcurrently]

Sorry for the noise.