If 2to3 is run on a file with the following contents:
a="string"
print ("%s" % a)

The output is:

a="string"
print (("%s" % a))

Although it was already a valid call to print in python3.

Thanks for the report. Is this similar to issue10375 ? One option would be to use -p to stop transforming print related code if you don't want to transform any print statement.


$ cat /tmp/foo.py
print (1)

$ 2to3 /tmp/foo.py
[snip]
--- /tmp/foo.py	(original)
+++ /tmp/foo.py	(refactored)
@@ -1 +1 @@
-print (1)
+print((1))

$ 2to3 -p /tmp/foo.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: No files need to be modified.

I suggest to close this issue as WONTFIX.

2to3 is designed as a tool to convert a Python 2 code base to Python 3 at once. I understand that once the code base is converted, you may want to revert some unwanted "useless" changes.

Python 2 and Python 3 languages have some intersections where it's hard to guess if the code is valid or not in Python 3. 2to3 uses heuristic which implements practical solutions. And you noticed, there are some corner cases where 2to3 generates useless changes.

IMHO 2to3 is fine. It may be nice to enhance it, but well, it's a trade-off, it's good as it is.

You may want to test other tools like modernize, 2to6, sixer, etc. which made different trade-offs.

Note: I'm the author of sixer and I'm not a big of 2to3 since it drops Python 2 support and generate many changes which are not needed since Python 3.2.

> 2to3 is designed as a tool to convert a Python 2 code base to Python 3 at once. I understand that once the code base is converted, you may want to revert some unwanted "useless" changes.

While this problem is likely to show up because someone has run 2to3 on a codebase more than once, I have *always* used parentheses around my print statements, even in pure Python 2, so it's not necessarily the case that this will cause problems.

I think this is a legitimate bug but also harmless since the code it generates is equivalent to the version with only one set of parentheses. I don't see a great deal of harm in marking this as low priority and leaving the bug open for someone to fix later, other than the fact that if someone comes along and fixes it, they may be discouraged to find that there are not really core developers interested in reviewing and merging the PR.

I will note that with the end of Python 2, 2to3 may become *more* relevant as fewer and fewer people are looking to translate code from 2->2/3 and more people will be looking to translate 2->3 directly.