As numpy is Python 3 only, these import statements are now unnecessary
and don't alter runtime behavior.

* Use list comprehension

* More list comprehension migration

* Revert key copying in dict

* A few more fixes

* More reverts

* Use dict comprehension

* Fix dict comprehension

* Address review comments

* More review comments

* Fix for empty unpacking of zip(*

* Revert zip(* unpacking altogether

* Fix dict copying

* More simplifications

The `getargspec` needed to import the disassembler to support parsing
tuple arguments. Since numpy never uses those, the corresponding code
is deleted and an TypeError raised if such arguments are encountered.

Also fix the unused formatargs function so it does not require the
string module.

Python 3 removes the builtin types from the types module. The types
fixer replaces such references with the builtin types where possible
and also takes care of some special cases:

    types.TypeNone           <- type(None)
    types.NotImplementedType <- type(NotImplemented)
    types.EllipsisType       <- type(Ellipsis)

The only two tricky substitutions are

    types.StringType         <- bytes
    types.LongType           <- int

These are fixed up to support both Python 3 and Python 2 code by
importing the long and bytes types from numpy.compat.

Closes #3240.

In Python 3 `map` is an iterator while in Python 2 it returns a list.
The simple fix applied by the fixer is to inclose all instances of map
with `list(...)`. This is not needed in all cases, and even where
appropriate list comprehensions may be preferred for their clarity.
Consequently, this patch attempts to use list comprehensions where it
makes sense.

When the mapped function has two arguments there is another problem that
can arise. In Python 3 map stops execution when the shortest argument
list is exhausted, while in Python 2 it stops when the longest argument
list is exhausted. Consequently the two argument case might need special
care. However, we have been running Python3 converted versions of numpy
since 1.5 without problems, so it is probably not something that affects
us.

Closes #3068

Add `print_function` to all `from __future__ import ...` statements
and use the python3 print function syntax everywhere.

Closes #3078.

The new import `absolute_import` is added the `from __future__ import`
statement and The 2to3 `import` fixer is run to make the imports
compatible. There are several things that need to be dealt with to make
this work.

1) Files meant to be run as scripts run in a different environment than
files imported as part of a package, and so changes to those files need
to be skipped. The affected script files are:

    * all setup.py files
    * numpy/core/code_generators/generate_umath.py
    * numpy/core/code_generators/generate_numpy_api.py
    * numpy/core/code_generators/generate_ufunc_api.py

2) Some imported modules are not available as they are created during
the build process and consequently 2to3 is unable to handle them
correctly. Files that import those modules need a bit of extra work.
The affected files are:

    * core/__init__.py,
    * core/numeric.py,
    * core/_internal.py,
    * core/arrayprint.py,
    * core/fromnumeric.py,
    * numpy/__init__.py,
    * lib/npyio.py,
    * lib/function_base.py,
    * fft/fftpack.py,
    * random/__init__.py

Closes #3172

2to3: Put `from __future__ import division` in every python file.

This should be harmless, as we already are division clean. However,
placement of this import takes some care. In the future a script
can be used to append new features without worry, at least until
such time as it exceeds a single line. Having that ability will
make it easier to deal with absolute imports and printing updates.