Catch SystemError in py3 Period.__richcmp__

[jbrockmendel]

First of ~3 to fix bugs reported in #17112. This just catches a py3-specific error in Period.__richcmp__ and raises the correct error instead. With a test that fails under the status quo.

[jreback]

I don't think SystemError exists in py2?

[jbrockmendel]

At least in 2.7.14 it does. I don't know about earlier off the top.

[jbrockmendel]

it's there in 2.7.12 and 2.7.9

[jreback]

why does other.freq != self.freq ever raise?

[jbrockmendel]

Your guess is as good as mine. Googling turned up some similar errors in Django, a suggestion that the GIL is involved. Hopefully we'll get to the root of the problem eventually. For now I'll be happy to just raise the right error.

Ref #17112, or to reproduce in py3:

>>> ser = pd.Series([pd.Period('2017'), pd.Period('2016Q1')])
>>> ser.sort_values()
[...]
SystemError: <built-in function isinstance> returned a result with an error set

[jreback]

this is just patching over the fundamental error, which is the self.freq != other.freq.
let's systematically test just this and try to repro, then this will be more clear.

[jreback]

comments

[jbrockmendel]

this is just patching over the fundamental error, which is the self.freq != other.freq.
let's systematically test just this and try to repro, then this will be more clear.

I agree on the patching over, but have gotten nowhere on actually figuring out what's going on. Open to suggestions.

[jreback]

I agree on the patching over, but have gotten nowhere on actually figuring out what's going on. Open to suggestions.

print out the case where this happens (e.g. both values). then add a test which systematically goes thru all the possibilities (e.g. maybe its a string comparing an offset or something). Then we can see exactly where the error is. having systematic unit tests is very important for basic things like this.

[jbrockmendel]

I think there may be a problem in the CI. Travis icon has said it is running for something like 2 days.

[jreback]

pls rebase on master and follow my comments above.

[jbrockmendel]

I'll try to follow that suggestion. The CI thing might need human intervention.

[jbrockmendel]

print out the case where this happens (e.g. both values). then add a test which systematically goes thru all the possibilities (e.g. maybe its a string comparing an offset or something).

AFAICT it isn't happening in scalar comparisons, only in index/series/frame sort_values (but not sort_index). The broken operations all seem to go through values.argsort().

In offsets if I wrap isinstance(other, compat.string_types) in a try/except that returns False on error, the bug is fixed. So the question is: what is it about np.argsort that messes with isinstance?

[jbrockmendel]

Closing because I'm concerned the never-ending Travis build may be clogging up the pipeline for others. Will return to this bug eventually.