Remove call to future standard_library.install_aliases()

[matthewhampton]

This is not safe to use in a library.

Also, please review the use of future in this library to make sure it is conservative enough not to cause trouble for other users of the library.

(or maybe consider modernize instead)

See #20 (comment)

[yaseen-mowzer-hexagon]

As far as I can tell modernize is just a 2to3 fixer like futurize, but unlike python-future doesn't backport modules from python 3 to python 2. One has to use modernize with six in order to write code that is valid python 2 and python 3.

Since we are already have futurized the code, reverting it back and then modernizing it seems like a waste of time, especially since the changes that futurize made were pretty conservative (See f86c386 and ea940f8) So I suggest we ignore modernize for now.

The question becomes then, should we use python-future or six? Future without install_aliases (but with from builtins import *) seems reasonably conservative, while allowing one to write clean Python 3 looking code. Six forces one to use awkward constructs such as six.text_type. Compare this to future where you can just use str.

The only thing we'll miss from future if we don't use install_aliases is these modules https://python-future.org/standard_library_imports.html#aliased-imports. (The other modules have been backported and do not have conflicting names in Python 2 so they don't need to install aliases).

The worse thing that we will do to other modules if we use future is that we may return future.types.new* instead of native python types. This shouldn't be much of a problem since python uses duck-typing, but if it does cause problems we could always call native on the values we return to ensure that we don't leak objects with weird types.

Given this I think it's better if we continue to use future, without install_aliases.

[matthewhampton]

Sounds reasonable to me!