-
- Notifications
You must be signed in to change notification settings - Fork 19.4k
BUG: Try to sort result of Index.union rather than guessing sortability #17378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
1ca8f9c to 35c2ec7 Compare Codecov Report
@@ Coverage Diff @@ ## master #17378 +/- ## ========================================== - Coverage 91.01% 90.99% -0.02% ========================================== Files 163 163 Lines 49567 49559 -8 ========================================== - Hits 45113 45096 -17 - Misses 4454 4463 +9
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@ ## master #17378 +/- ## ========================================== - Coverage 91.72% 91.72% -0.01% ========================================== Files 150 150 Lines 49122 49104 -18 ========================================== - Hits 45057 45039 -18 Misses 4065 4065
Continue to review full report at Codecov.
|
| warnings.warn("%s, sort order is undefined for " | ||
| "incomparable objects" % e, RuntimeWarning, | ||
| stacklevel=3) | ||
| try: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you probably can simply use core.sorting.safe_sort here instead and just remove the warning entirely (as it fails in many less cases)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, but I left the warning as it's still raised if not even safe_sort can sort them.
(I assume the failure is a problem with AppVeyor)
0a0e0f2 to 0a725fc Compare bc4b8ba to e533022 Compare | Any idea about what's happening with AppVeyor? It fails reliably on this PR with 2.7, but the trace doesn't point at any specific test. |
| @toobaz : Nope, not a clue 😢 . There's no way your changes AFAICT could have caused internal errors on the build. I restarted AppVeyor to double check. |
Failed again... shall I try closing this and opening a new PR? |
NO. that just creates more work. let me look. |
| ok this is a legitimate catch. pytest-dist is segfaulting, hiding the traceback. So a couple of options to debug. setup a vm on 3.6/windows is easiest / best. you can temporarily change the options in the test runner (in ci/scripts_multiple.py) to something like: which disables the multi-processing and shows each test (so you can see where its failing). |
| it looks like its either segfaulting or in a recursive loop somewhere. |
Do you mean Python 3.6?! (tests fail only on 2.7) |
Certainly related, but I'm confused: are you suggesting the two methods should share more code? Or just that |
e533022 to 83398d9 Compare
yes I would add a |
| can you rebase. I think we do want to add this kw. |
83398d9 to decaa47 Compare | Unfortunately the problem on Windows + Python 2.7 persists. I haven't found the time to set up a virtual machine to debug. |
| @toobaz if you can rebase would be great. I would also be ok with simply adding the keyword w/o changing much code as a first step. |
| Hmmm...so this issue might be known with pytest (or its plugins) already: Still not sure how @toobaz is triggering that though. Unless anyone has any other insights into this, I feel inclined to file an issue against one of the pytest repositories and see what they have to say. |
| Maybe we could ask whether there is a way to use this catchsegv within a pytest run? |
@toobaz : Well, this is a Windows machine, not UNIX 😢 I notice that we are using pytest-forked, which AFAICT, isn't well-supported on Windows: https://github.com/pytest-dev/pytest-forked I was about to file an issue against pytest-xdist, but I wonder if this might be the problem child. |
right 🙄
What makes you think this is a bug in pytest, not a segfault somewhere in pandas? (or do you think it's both?) |
I'm highly skeptical that your changes are causing a segfault. That would be pretty impressive actually given that you're only touching high-level Python 😄 In addition, I've tested your changes on multiple OS's (Windows including). No segfault anywhere. |
156fd86 to f4571a2 Compare | So removing xdist + rebasing somehow resulted in test failures on the first machine? Going to leave this PR alone for now until |
Sure, that would require that my changes are triggering a bug somewhere in lower-level code... but I consider this more probable than a bug in pydist which affects precisely that test, in precisely this PR. Then again, I'm definitely not an expert. |
| I suppose, but if it's a bug in your code, I haven't been able to reproduce it locally. |
Aha! I had missed that you were testing on Windows. Good to know. |
f4571a2 to 953ccc6 Compare This will probably slow down performance, but I can't see where the bug is in the changes.
953ccc6 to 899c040 Compare | | ||
| # create our env | ||
| - cmd: conda create -n pandas python=%PYTHON_VERSION% cython pytest>=3.1.0 pytest-xdist | ||
| - cmd: conda create -n pandas python=%PYTHON_VERSION% cython pytest>=3.1.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so does xdist cause the issues with this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really hard to tell at the moment. I've just been experimenting. I'm just at a loss right now as to how that one build on AppVeyor is crashing is so badly with changes like these.
| @toobaz : It appears that you loosened the sorting restrictions too much, at least for Windows:
|
| @gfyoung thanks for your analysis! Does the problem arise with any specific combination of index types? (from |
I can't tell unfortunately. It seems to have crashed with multiple types. |
| @toobaz whats' the status on this? |
| closing as stale, if you want to continue working, pls ping and we can re-open. you will need to merge master. |
git diff master -u -- "*.py" | flake8 --diffThe lines of code I removed seemed written with the intention of guaranteeing the same result under Python 2 and 3, but the docs say "Form the union of two Index objects and sorts if possible.": so if it is possible in Python 2 we should do it, regardless of whether it is in Python 3. After all, this is how
.sort_values()works. And more practically, trying to guess whether the result of an union can be sorted is hard.