Skip to content

bpo-39320: Don't use an oparg for new DICT_* opcodes. #18243

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 4 commits into from
Closed

bpo-39320: Don't use an oparg for new DICT_* opcodes. #18243

wants to merge 4 commits into from

Conversation

@brandtbucher
Copy link
Member

@brandtbucher brandtbucher commented Jan 29, 2020 •
edited by bedevere-bot
Loading

The oparg for these new, simpler opcodes is always 1. @markshannon

https://bugs.python.org/issue39320
@brandtbucher brandtbucher reopened this Jan 29, 2020
@brandtbucher brandtbucher added the type-feature A feature request or enhancement label Jan 29, 2020
@markshannon
Copy link
Member

markshannon commented Jan 29, 2020

I'd prefer to keep the new opcodes as they are.

There is no efficiency gain in ignoring the oparg, as it is always pre-computed during dispatch.
Allowing flexible access into the stack may allow compiler optimisations that your change would prevent.
@brandtbucher
Copy link
Member Author

brandtbucher commented Jan 29, 2020

That makes sense; thanks for the quick review!
@brandtbucher brandtbucher deleted the map-opargs branch July 21, 2022 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting review type-feature A feature request or enhancement

4 participants

@brandtbucher @markshannon @the-knights-who-say-ni @bedevere-bot