DOC/PY3: np.unique errors on pd.Series with mixed string/float in python3

[phaebz]

In a similar fashion as #6212, the following fails on Python 3 (doc/source/reshaping.rst):

import numpy as np
import pandas as pd
x = pd.Series(['A', 'A', np.nan, 'B', 3.14, np.inf])
np.unique(x, return_inverse=True)[::-1])

/Users/user/.virtualenvs/pandas-dev/lib/python3.3/site-packages/numpy/lib/arraysetops.py in unique(ar, return_index, return_inverse)
    181             perm = ar.argsort(kind='mergesort')
    182         else:
--> 183             perm = ar.argsort()
    184         aux = ar[perm]
    185         flag = np.concatenate(([True], aux[1:] != aux[:-1]))

TypeError: unorderable types: str() > float()

Although this error manifests in numpy code, I assume this has to do with pd.Series?

[jreback]

numpy/numpy#641

this is a numpy bug in py3 when trying to order mixed (strings and numbers)
it works in py2, but fails in py3

There is a solution which I used for pandas (and which numpy will do something similar at some point)

so this example is just showing that factorize replaces np.uniques but with a better ordering

I think maybe just change this to a code block for the numpy part. (but leave the factorize their)

reminds me to add a test for this explicitly ( it is indirectly tested in #6212)

as no way to fix

[phaebz]

Ok, thanks for the info.

I think maybe just change this to a code block for the numpy part. (but leave the factorize their)

Do you mean to split it into two code blocks?

As a side note and since it would help me with the py2/3 docs compat: Do you know of a good way to handle this during the doc building so we can close this? I am thinking along the lines of conditional parts in .rst files. That would also help with problems such as StringIO vs. BytesIO etc.

[jreback]

u could put those 2 lines in a code block is fine

I think u can so conditionals with compat.PY3 in a suppressed I python block

[phaebz]

Ok, will try.

[jreback]

@phaebz this is covered in #6230?

[phaebz]

Not yet. I figured waiting for numpy/numpy#641 would be better. What do you think?

[jreback]

nope
I'll see when they fix it
not in 1.9
you will be waiting a long time

go ahead and just change it (if u really want to u can put in a note that numpy will throw an error - and point to the bug -might be useful

[phaebz]

Added note, see latest commit in #6230.

[phaebz]

"Fixed" (comment on doc example failure) in #6230.