The "has_key" fixer in 2to3 produces wrong code on the following example:

input:"a.has_key(b)and x"
output:"b in aand x"

Note the lack of space before "and" in the input.

I am unable to replicate this issue with '2to3' from Python 2.7.12, Python 3.4.5, nor Python 3.5.2.

Below is what I get with the versions I mentioned above.

---

$ cat test.py
a.has_key(b) and x

$ 2to3 test.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Refactored test.py
--- test.py    	(original)
+++ test.py    	(refactored)
@@ -1 +1 @@
-a.has_key(b) and x
+b in a and x
RefactoringTool: Files that need to be modified:
RefactoringTool: test.py

---

Eric, remove the space from after the has_key call to match OP:

$ cat test.py
a.has_key(b)and x

It's legal to omit the space there.

Testing it myself that way:

C:\>type test.py
a.has_key(b)and x

C:\>"C:\Program Files\Python 3.5\Tools\scripts\2to3.py" test.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Refactored test.py
--- test.py     (original)
+++ test.py     (refactored)
@@ -1 +1 @@
-a.has_key(b)and x
+b in aand x
RefactoringTool: Files that need to be modified:
RefactoringTool: test.py

> Eric, remove the space from after the has_key call to match OP:

> $ cat test.py
> a.has_key(b)and x

Good catch.  Disregard msg273622 from me - I am able to replicate what the OP has described.

I don't think it is necessary or reasonable to expect 2to3 to handle this.  It is a tool for the developer to use, so just clean up the input.

I have one line change to "Lib/lib2to3/fixes/fix_has_key.py" that will resolve this issue.  Would a patch be accepted?

It doesn't seem like the input is unusually contorted.

If you don't want to sign the CA, https://www.python.org/psf/contrib/, and upload a file without a guarantee, which is never given ;-), just give the patch in a text message.  While it may be unreasonable to *expect* 2to3 to handle this, it also might not be unreasonable for it to do so.  It would be especially useful if one were converting to Py3 and not planning to maintain the 2.x code.

My concern is that this might be one of multiple similar situations, so that patching just one might not be all that helpful.  But I have not looked at the list of fixers to determine is other are affected.

messages: + msg273715
versions: + Python 3.5, Python 3.6, - Python 3.4

messages: + msg273673

nosy: + r.david.murray
messages: + msg273646

resolution: rejected
stage: resolved