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.

Title: str object got multiple values for keyword argument
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.6, Python 3.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: ishcherb, jpe, larry, lukasz.langa, mark.dickinson, martin.panter, ncoghlan, python-dev, rhettinger, serhiy.storchaka, shai
Priority: normal Keywords: patch

Created on 2016-06-10 09:37 by martin.panter, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit
BUILD_MAP_UNPACK_WITH_CALL-function_pos.patch serhiy.storchaka, 2016-06-10 13:15 review
BUILD_MAP_UNPACK_WITH_CALL-function_pos2.patch serhiy.storchaka, 2016-06-10 16:59 review
Pull Requests
URL Status Linked Edit
PR 169 merged ncoghlan, 2017-02-19 07:24
Messages (13)
msg268110 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2016-06-10 09:37
Playing with the generalized unpacking (PEP 448), I found a funny error message, when duplicate dictionary unpackings are included and also duplicate a literal keyword argument:

>>> print(end=".\n", **dict(end="dupe"))  # No problem
TypeError: print() got multiple values for keyword argument 'end'
>>> print(**dict(end=".\n"), **dict(end="dupe"))  # No problem
TypeError: print() got multiple values for keyword argument 'end'
>>> print(end=".\n", **dict(end="dupe"), **dict(end="dupe 2"))  # str object?!
TypeError: str object got multiple values for keyword argument 'end'
msg268121 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-06-10 13:15
Here is a fix.
msg268123 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-06-10 15:46
This patch looks correct.
msg268128 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-06-10 16:59
Since currently generated bytecode is not correct, I think we should update the magic number for forcing the regenerating pyc-files.
msg268336 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-06-12 06:49
New changeset 34d24c51eab6 by Serhiy Storchaka in branch '3.5':
Issue #27286: Fixed compiling BUILD_MAP_UNPACK_WITH_CALL opcode.  Calling

New changeset 194549801bd5 by Serhiy Storchaka in branch 'default':
Issue #27286: Fixed compiling BUILD_MAP_UNPACK_WITH_CALL opcode.  Calling
msg272360 - (view) Author: John Ehresman (jpe) * Date: 2016-08-10 19:10
Should the bytecode magic number be bumped in the 3.5 branch?  This breaks .pyc / .pyo binary compatibility for python 3.5.  As far as I can tell this has never been done before in a release after the major.minor.0 final release.

This patch has made its way into debian's python 3.5 and I've gotten a bug report because of it for an app distributed without python source.

Looking at the 3.5.2 tarball, it does not look like the change was included in 3.5.2.  If the magic number is bumped in 3.5, the comment should be changed to reflect that it changes in 3.5.3 and not in 3.5.2
msg272368 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2016-08-10 19:46
Bytecode generated by 3.5.1 is not correct (wrong error message can be not the only effect). The only way to resolve this issue is regenerating the bytecode.

3.5.2 was released two weeks after committing this patch. I expected it includes this change.
msg278158 - (view) Author: Łukasz Langa (lukasz.langa) * (Python committer) Date: 2016-10-05 23:29
The magic number change in a minor release was a mistake. Let's not do that with 3.6.x releases. Since Python doesn't check if there's a corresponding .py file that can be used to rebuild the .pyc file, we shouldn't reject existing .pyc files on the basis that they *might* be broken.
msg282148 - (view) Author: Shai Berger (shai) Date: 2016-12-01 08:54
Following the last comment, and just as clarification for anyone else running into this and thinking like me: The bumped code is not included in v3.5.2, and v3.5.3 hasn't been released yet. Should it be undone?

No, because the bump which was encountered by John Ehresman on Debian Testing has also made it into Ubuntu 16.04LTS. Undoing it, at this point, is liable to bring even worse breakage than the original change caused.
msg287506 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2017-02-10 10:44
It's difficult to track down which versions of Python 3.5.x the bytecode change is in because the Misc/NEWS entry has vanished, apparently in this merge commit:
msg287508 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2017-02-10 10:45
Sorry about that!  It's almost like manually updating Misc/NEWS is a bad design :(
msg287526 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-02-10 12:41
Diff showing what changed relative to the main 3.5 branch when merging in the 3.5.2 release: <>.

There are four news entries deleted from the 3.5.2rc1 section. Ideally they should have been moved to the 3.5.3rc1 section instead, because they were added after 3.5.2rc1 was branched, but before the 3.5.3rc1 heading appeared.

Also, there were some minor corrections of mine and Victor’s that were undone.

And I would suggest to restrict merge commits to changes that are already in at least one of the branches being merged. The edit to “byte-like” was not present in either of the branches being merged. In Git I think they call these changes “evil merges”.
msg290270 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-03-24 22:42
New changeset 93602e3af70d3b9f98ae2da654b16b3382b68d50 by Nick Coghlan in branch '3.5':
[3.5] bpo-29537: Tolerate legacy invalid bytecode (#169)
Date User Action Args
2022-04-11 14:58:32adminsetgithub: 71473
2017-03-24 22:42:19ncoghlansetnosy: + ncoghlan
messages: + msg290270
2017-02-19 07:24:46ncoghlansetpull_requests: + pull_request134
2017-02-13 12:30:07ishcherbsetnosy: + ishcherb
2017-02-10 12:41:27martin.pantersetmessages: + msg287526
2017-02-10 10:45:51larrysetmessages: + msg287508
2017-02-10 10:44:44mark.dickinsonsetnosy: + mark.dickinson
messages: + msg287506
2016-12-01 08:54:43shaisetnosy: + shai
messages: + msg282148
2016-10-05 23:29:06lukasz.langasetnosy: + lukasz.langa
messages: + msg278158
2016-08-10 19:46:19serhiy.storchakasetnosy: + larry
messages: + msg272368
2016-08-10 19:10:39jpesetnosy: + jpe
messages: + msg272360
2016-06-12 07:41:31serhiy.storchakasetstatus: open -> closed
assignee: serhiy.storchaka
resolution: fixed
stage: patch review -> resolved
2016-06-12 06:49:48python-devsetnosy: + python-dev
messages: + msg268336
2016-06-10 16:59:49serhiy.storchakasetfiles: + BUILD_MAP_UNPACK_WITH_CALL-function_pos2.patch

messages: + msg268128
2016-06-10 15:46:17rhettingersetnosy: + rhettinger
messages: + msg268123
2016-06-10 13:15:43serhiy.storchakasetfiles: + BUILD_MAP_UNPACK_WITH_CALL-function_pos.patch

nosy: + serhiy.storchaka
messages: + msg268121

keywords: + patch
stage: patch review
2016-06-10 09:37:11martin.pantercreate