RF: move to six.py module for py3k compatibility

Add six.py module instead of py3k module where possible.

Rely on b'' literals in Python 2.6 instead of asbytes
RF: update netcdf from scipy

Adapt doctests so they run and don't leave temporary files.
RF: use print_function in obvious cases

Instead of print statement

Use future division by default with new __future__ imports.
RF: import configparser safely for Python3

using six.py
RF: reorganize gifti imports for Python 3

Python 3 choking on the circular imports
RF: update onetime module from dipy

Dipy had later and refactored copy.
RF: remove use of xrange

For Python 3 compatibility
RF: remove use of "has_key"

in favor of "key in dict"
RF: refactor StringIO to BytesIO, StringIO

Use six module to import BytesIO and StringIO.
Remove unused StringIO import
RF: cleared up old exception syntax for dft

dft and tests still using old exception syntax
RF: import reduce for Eulerangles
RF: add list() round Python 3 iterators

list() round range(), output of map(), zip()
RF: use next function instead of next method

For iteration
RF: remove 23dt doctest markup

Use b'' literal and io module instead.
RF: bytes / str doctests check equality not out string

Avoid spurious failures for b'' rather than ''
RF: get keys into list before dict iteration

to avoid altering dict during iteration over keys, and therefore a
Python 3 error.
RF+TST: force int_to_float input to Python integer

It seems that there is some difference in the way that numpy outputs min
/ max values for integers, so that sometimes we were passing np.uint64
values, causing subtle or obvious errors when converting to floats.
RF: turn off 2to3 conversion during py building

The code should be compatible with Pythons 2 and 3
BF: remove unicode literal for Python 3.2

Using u'' which is a syntax error for Python 3 < 3.3
BF : workaround for broken complex256 on Python 3

Bizarre errors with byteswapped versions of complex256, apparently only
on Python 3.3, with numpy 1.7.0 - but - we'll see.

Errors were in `test_arraywriters`, claiming that two complex256 arrays
differing only in native, swapped endianness compared unequal. Debugging
showed that numpy was finding nans in the byteswapped array, and
subtraction results were odd, etc.