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 problemTypeError: print() got multiple values for keyword argument 'end'>>> print(**dict(end=".\n"), **dict(end="dupe"))  # No problemTypeError: 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'

Here is a fix.

This patch looks correct.

Since currently generated bytecode is not correct, I think we should update the magic number for forcing the regenerating pyc-files.

New changeset34d24c51eab6 by Serhiy Storchaka in branch '3.5':Issue#27286: Fixed compiling BUILD_MAP_UNPACK_WITH_CALL opcode.  Callinghttps://hg.python.org/cpython/rev/34d24c51eab6New changeset194549801bd5 by Serhiy Storchaka in branch 'default':Issue#27286: Fixed compiling BUILD_MAP_UNPACK_WITH_CALL opcode.  Callinghttps://hg.python.org/cpython/rev/194549801bd5

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

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.

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.

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.http://changelogs.ubuntu.com/changelogs/pool/main/p/python3.5/python3.5_3.5.2-2ubuntu0~16.04.1/changelog

It's difficult to track down which versions of Python 3.5.x the bytecode change is in because theMisc/NEWS entry has vanished, apparently in this merge commit:https://github.com/python/cpython/commit/aa0f9d8f26bbe63adcbce950aaadc844d996e7ac

Sorry about that!  It's almost like manually updatingMisc/NEWS is a bad design :(

Diff showing what changed relative to the main 3.5 branch when merging in the 3.5.2 release: <https://hg.python.org/cpython/rev/31a2a278dc85:1f8938164809>.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”.

New changeset93602e3af70d3b9f98ae2da654b16b3382b68d50 by Nick Coghlan in branch '3.5':[3.5]bpo-29537: Tolerate legacy invalid bytecode (#169)https://github.com/python/cpython/commit/93602e3af70d3b9f98ae2da654b16b3382b68d50