Mutating a bytes object is theoretically unsafe, but doesn't cause any
problem in any existing version of CPython.

Previously NumPy did not compile in Python 3.3 due to the changes in PEP 393.
This patch simply calls PyUnicode_FromKindAndData() from the new Python 3.3 API
and possibly swaps the data before calling it if needed. The data in NumPy is always UCS4 and the PyUnicode_FromKindAndData() internally converts it to UCS1, UCS2 or UCS4 depending on the maximum code point.

The following tests now fail, because they produce invalid unicode in the
process (will be fixed in the next patch):

======================================================================
ERROR: Check byteorder of 0-dimensional objects
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ondrej/py33/lib/python3.3/site-packages/numpy/core/tests/test_unicode.py", line 277, in test_values0D
    self.assertTrue(ua[()] != ua2[()])
SystemError: invalid maximum character passed to PyUnicode_New

======================================================================
ERROR: Check byteorder of multi-dimensional objects
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ondrej/py33/lib/python3.3/site-packages/numpy/core/tests/test_unicode.py", line 297, in test_valuesMD
    self.assertTrue(ua[0,0,0] != ua2[0,0,0])
SystemError: invalid maximum character passed to PyUnicode_New

======================================================================
ERROR: Check byteorder of single-dimensional objects
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ondrej/py33/lib/python3.3/site-packages/numpy/core/tests/test_unicode.py", line 286, in test_valuesSD
    self.assertTrue(ua[0] != ua2[0])
SystemError: invalid maximum character passed to PyUnicode_New

======================================================================
ERROR: Check byteorder of 0-dimensional objects
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ondrej/py33/lib/python3.3/site-packages/numpy/core/tests/test_unicode.py", line 277, in test_values0D
    self.assertTrue(ua[()] != ua2[()])
SystemError: invalid maximum character passed to PyUnicode_New

======================================================================
ERROR: Check byteorder of multi-dimensional objects
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ondrej/py33/lib/python3.3/site-packages/numpy/core/tests/test_unicode.py", line 297, in test_valuesMD
    self.assertTrue(ua[0,0,0] != ua2[0,0,0])
SystemError: invalid maximum character passed to PyUnicode_New

======================================================================
ERROR: Check byteorder of single-dimensional objects
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ondrej/py33/lib/python3.3/site-packages/numpy/core/tests/test_unicode.py", line 286, in test_valuesSD
    self.assertTrue(ua[0] != ua2[0])
SystemError: invalid maximum character passed to PyUnicode_New

The tests are testing byte order for unicode, so we can only use such unicode
data, so that both versions (swapped and unswapped) are valid unicode.

Temporary array was not being freed after use.

This function handles the swapping automatically and it returns a unicode
object in one of: UCS1, UCS2 or UCS4 internal Python format.

It comes from the Python compiler package, which isn't available on Python 3.x.
We already handle that issue by instead importing the ast module.

Fixes numpy#369 and the Ticket 2185

Thanks to @seberg for providing the patch.

Fix returned copy so that copy of view with offsets copies only fields in view, not all the fields from original array. Also add unit tests to make sure this doesn't break when copy is fully deprecated in favor of returning a view.

This patch enforces a strict dichotomy for the variables 'indescr'
and 'newdescr', so they are either NULL, or they own a reference.
Following the consequences of this allowed the reference error
to be tracked down.

The bug was fixed by the previous patch.

Fixes numpy#416

This should fix the problems with numpy.insert(), where the input values
were not checked for all scalar types and where values did not get inserted
properly, but got duplicated by default.

The problem was that in 32bit Ubuntu 12.04, one gets the following:

>
/home/njs/numpy/.tox/py27/local/lib/python2.7/site-packages/numpy/random/tests/test_random.py(363)test_pareto()
-> np.testing.assert_array_almost_equal(actual, desired, decimal=15)
(Pdb) actual[1, 0]
52828779.702948704
(Pdb) desired[1, 0]
52828779.702948518

and the test was comparing the numbers to 1e-14, which obviously
failed.

Fixes numpy#424.

Travis recently upgraded to virtualenv 1.8, which has dropped support
for Python 2.4. So, in our Python 2.4 setup script, we need to
explicitly fetch and use virtualenv 1.7. Likewise for pip 1.1.

File imported from the already-fixed version for patsy:
  https://github.com/pydata/patsy/blob/0316d2901f4195db06e8091c15f37d9fe4ad09de/.travis-make-py24-virtualenv.sh