String conversion breaks string type checks

[jaraco]

Consider this failing example:

$ cat > test-future.py
x = str(3)
allowed_types = basestring, int
assert isinstance('', allowed_types)
$ futurize test-future.py -w 
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored test-future.py
--- test-future.py  (original)
+++ test-future.py  (refactored)
@@ -1,3 +1,4 @@
+from builtins import str
 x = str(3)
-allowed_types = basestring, int
+allowed_types = str, int
 assert isinstance('', allowed_types)
RefactoringTool: Files that were modified:
RefactoringTool: test-future.py
$ python2.7 test-future.py
Traceback (most recent call last):
  File "test-future.py", line 4, in <module>
    assert isinstance('', allowed_types)
AssertionError

Here you see a simple example where a file that worked on Python 2 before futurize fails on Python 2 after futurize. Interestingly, it's the str(3) that triggers the import of str which breaks the type check.

Similarly, if the type being checked is unicode, futurize also breaks it:

$ cat > test-future.py
assert isinstance(u'foo', basestring)
$ python2.7 test-future.py
$ futurize test-future.py -w 
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored test-future.py
--- test-future.py  (original)
+++ test-future.py  (refactored)
@@ -1 +1 @@
-assert isinstance(u'foo', basestring)
+assert isinstance(u'foo', str)
RefactoringTool: Files that were modified:
RefactoringTool: test-future.py
$ python2.7 test-future.py
Traceback (most recent call last):
  File "test-future.py", line 1, in <module>
    assert isinstance(u'foo', str)
AssertionError

The six project handles this by using a special variable string_types for doing type comparisons for strings.

What is the solution for future?

[edschofield]

futurize in v0.15.0 has a custom basestring fixer that imports the compatibility class basestring from past.builtins. So I believe this works now.

There's also now a string_types alias in future.utils in case you'd prefer to use that idiom.

Please feel free to re-open this issue if you have any further problems.