PR: Fix error when attempting to view module contents in CollectionsEditor #6081
Conversation
| @@ -265,5 +269,14 @@ def test_edit_mutable_and_immutable_types(qtbot, monkeypatch): | |||
| readonly=True) | |||
|
|
|||
|
|
|||
| def test_view_module_in_coledit(qtbot, monkeypatch): | |||
| """Checks that modules don't produce an error when trying to open them in | |||
There was a problem hiding this comment.
Please change Checks to Check
There was a problem hiding this comment.
Oops; fixed the one above but missed that one. Thanks for the catch; corrected now.
|
@CAM-Gerlach, could you post a screenshot to see how it looks to view a module in the Variable Explorer now? |
|
Sure, here ya go, though it wasn't really at all my doing. Is it SOP to post screenshots of any GUI visible changes from a PR?
|
|
Not sure what was up with the one failed Travis CI check. My test passed locally in several trials, and did the same for every commit (all three should be functionally identical), every build on every platform, except for the one Py3.5, PyQt4 build on Travis that failed, due to my test causing an exception to occur. However, I told it to rerun that build and, of course, it passed again this time. Any idea how such a simple test could possibly be randomly unreliable in rare cases like that? It seems the one time it failed, it was because the exception that it now catches wasn't thrown as it was supposed to be inside the deepcopy function, and so it proceeded until it hit a different exception and then errored out. Here's the build output if that's helpful. Of course, I could catch that exception too but that would be silly, since it should never actually throw it in the first place. Seems the problem might be with deepcopy not always throwing the error consistently? If so, how could something relatively simple like that be inconsistent—where's the entropy coming from? |
Nop, sorry. Sometimes tests fail for no good reason. So please add the |
|
Did so, but now seeing the same failure on a different build, and it seems it either passes all three flaky tests or fails all three, so it seems something further needs to be done. As it seems the unreliability is in |
|
Also, out of curiosity, is there a reason |
That's Pierre's work, so no idea. |
|
It couldn't have anything to do with the issue, I wouldn't think? Other than that, is this good to go? |
Fixes #6080 , where Spyder would produce an error instead of viewing module contents, likely related to the recent introduction of
cloudpickle.Also includes a regression test making sure the editor is created without error and is properly readonly.