This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author xmorel
Recipients Mark.Shannon, xmorel
Date 2020-10-14.10:48:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1602672511.92.0.360571035375.issue42033@roundup.psfhosted.org>
In-reply-to
Content
Following bpo-39320 the highly specialised bytecode for vararg calls were replaced by simpler ones, but there seems to be at least one area where the generated bytecode regressed for possibly no reason?

In Python 3.8, foo(**var) compiles to:

0 LOAD_GLOBAL              0 (foo)
2 BUILD_TUPLE              0
4 LOAD_FAST                2 (var)
6 CALL_FUNCTION_EX         1

In Python 3.9, it compiles to:

0 LOAD_GLOBAL              0 (foo)
2 BUILD_TUPLE              0
4 BUILD_MAP                0
6 LOAD_FAST                2 (var)
8 DICT_MERGE               1
0 CALL_FUNCTION_EX         1

The PR 18141 does not seem to change the implementation of CALL_FUNCTION_EX so I would expect that if it was fine with taking the `var` arbitrary mapping before it stil is now, and the extra two opcodes (and creation of a dict) is unnecessary?
History
Date User Action Args
2020-10-14 10:48:31xmorelsetrecipients: + xmorel, Mark.Shannon
2020-10-14 10:48:31xmorelsetmessageid: <1602672511.92.0.360571035375.issue42033@roundup.psfhosted.org>
2020-10-14 10:48:31xmorellinkissue42033 messages
2020-10-14 10:48:31xmorelcreate