is it planned at 3.12.1? the only problem for pyinstaller + scipy user

I would like it to be but someone has to review it.

Thanks @JelleZijlstra! I am back from vacation and looking at this issue/PR.

Thanks! This solution works but I'm not really happy with it; if you have a better idea, that'd be great.

I think the solution that would be most in-line with the current design of code objects would be to add a co_fasthidden accessor on code objects, and corresponding new argument to both code_new and code_replace. If the new argument is not provided, it would fall back to marking the same names as "fast hidden" that were marked as such in the original code object (just like it currently does for co_freevars etc.) This is what I would have done in the first place in 3.12, if I'd realized the issue with code.replace().

I think this is better because it places full control into the hands of callers of code.replace() (and creators of new synthetic code objects), rather than implicitly tying CO_FAST_HIDDEN to LOAD_FAST_AND_CLEAR in the bytecode. This allows creation of broken code objects, of course, but there are already many ways to create broken code objects.

The main unpleasant consequence here would be the need to add a new PyUnstable_Code_NewWithFastHidden API (maybe technically we are allowed to modify the signature of an existing PyUnstable_*, but adding a new function seems much nicer than breaking users of the existing function, especially in a bugfix release).

But adding to the signature of code_new and code_replace in a bugfix release is not great either, even if it's backward compatible (new optional argument at the end), since it means that users of those APIs who use the new argument in their code would need to check for Python version >= 3.12.1.

So maybe we should take my suggested approach only for 3.13, and use your PR for 3.12? What do you think?

That does seem like a better long-term solution, but I'm also hesitant to make that sort of change in the 3.12 branch at this point. So I agree with your suggestion to apply this PR's solution to 3.12 and add new arguments to the constructor for 3.13.

Thanks @JelleZijlstra for the PR, and @carljm for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

GH-111866 is a backport of this pull request to the 3.12 branch.