-
-
Notifications
You must be signed in to change notification settings - Fork 18.2k
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
BUG: Try to sort result of Index.union rather than guessing sortability #17378
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
@@ -73,7 +73,7 @@ install: | |||
- cmd: conda info -a | |||
|
|||
# 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 --diff
The 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.