Skip to content

TST: Fail on warning #22699

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

Merged
merged 42 commits into from
Sep 18, 2018
Merged

Conversation

TomAugspurger
Copy link
Contributor

@TomAugspurger TomAugspurger commented Sep 13, 2018

Sets our pytest config to fail on unhandled warnings.

Fixes a bunch of tests to not fail.

This still has a few TODOs.

Closes #16481
Closes #19677
Closes #13962
Closes #22020

@TomAugspurger TomAugspurger added the Testing pandas testing functions or related to the test suite label Sep 13, 2018
@TomAugspurger TomAugspurger added this to the 0.24.0 milestone Sep 13, 2018
@rth
Copy link
Contributor

rth commented Sep 13, 2018

Fixing all the warnings is definitely great!

About harcoding -Werror in setup.cfg that can lead to various issues (cf scikit-learn/scikit-learn#12043 for more details). Adding those flags in CI setup might be more robust. Among other things hardcoding such a flag in setup.cfg may lead to the test suite failing (without good reason) with older or not yet released versions of dependencies, when using PyPy or some other less common environments.

@h-vetinari
Copy link
Contributor

If it turns all warnings into errors, it might close #13962 as well.

@TomAugspurger
Copy link
Contributor Author

@rth thanks for the context, that's helpful. I think that elevating warnings to errors only on worker with the latest dependencies makes the most sense. I'll probably keep at this until things are passing, and then limit the elevation once things are passing.

If it turns all warnings into errors, it might close #13962 as well.

Thanks for the link. It should close that.

@@ -31,6 +32,16 @@ def pytest_addoption(parser):
help="Fail if a test is skipped for missing data file.")


def pytest_collection_modifyitems(items):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we'll want this permanently. This is just to track down #22675 in case it happens on this branch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this as part of the ultimate change or no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm tempted to leave it in master for a week or two to see if we catch any of the failures in action. I've made myself a reminder to remove it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sighhhhhhhhhhhhhhhhhhhhhhhhhhhh. we got one: https://travis-ci.org/pandas-dev/pandas/jobs/429657921#L2280, but that doesn't actually fail the right test, because the warning is in the file object's __del__, just prints out to stderr rather than raising an exception (to fail the test).

I'm going to do some debugging on the branch.

@TomAugspurger
Copy link
Contributor Author

I wasn't able to get the suggestion of

error:::pandas[.*]

to work reliably. In my small test of

def test_warns():
    pd.Panel()
    pd.DataFrame({"A": [1, 2]}).ix[0]

the panel warning was not elevated to an error, but the .ix was. I didn't investigate too deeply.

@TomAugspurger
Copy link
Contributor Author

Those interested in the ResourceWarning failures may want to take a look at cfb5ae2. I tried to squash all the places we may have had unclosed files sitting around. If I had to guess, either cfb5ae2#diff-0d7b5a2c72b4dfc11d80afe159d45ff8R389 or cfb5ae2#diff-9d7323cc6b0cfa3f4482bc8d4268966dR213 is going to be the one that fixes it, but who knows.

@TomAugspurger
Copy link
Contributor Author

I think I've addressed all the inline comments

Sorry to push on this relatively quickly, but I want to get our CI in a healthy state again. If possible, I'd like to merge this today.

I currently have two followup issues for warnings that need some care

  1. Handle FutureWarning from NumPy in Series Construction #22698 (Series ctor)
  2. Unhandled warning from NumPy dev in median #22712 (median with all-NA slice)

@jreback can you clarify our current policy on "allowed failures"? I don't recall why they're in the allowed-failures section.

Copy link
Contributor

@jreback jreback left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomAugspurger awesome effort here. This was for sure a sore point. Some minor comments.

with tm.assert_prodcues_warning(FutureWarning):
df.some_operation()

We prefer this to the ``pytest.warns`` context manager because ours checks that the warning's
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you may want to mention that we will actually fail if pytest.warns will fail the linter :>

(dtype.startswith("Int") or dtype.startswith("UInt"))):
# Avoid DeprecationWarning from NumPy about np.dtype("Int64")
# https://github.com/numpy/numpy/pull/7476
dtype = dtype.lower()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh I didn't know numpy did this:

In [1]: np.dtype('Int64')
/Users/jreback/miniconda3/envs/pandas/bin/ipython:1: DeprecationWarning: Numeric-style type codes are deprecated and will result in an error in the future.
  #!/Users/jreback/miniconda3/envs/pandas/bin/python
Out[1]: dtype('int64')

I guess so, thanks

@@ -758,7 +758,7 @@ def aggregate(self, func_or_funcs, *args, **kwargs):
if isinstance(func_or_funcs, compat.string_types):
return getattr(self, func_or_funcs)(*args, **kwargs)

if isinstance(func_or_funcs, collections.Iterable):
if isinstance(func_or_funcs, compat.Iterable):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in theory we could add a lint rule to avoid using collection.Iterable, and instead just use our compat

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we're close enough to py3-only that we'll be OK. Writing that regex would be a bit fiddly since we'd need to enumerate all the ABCs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, certainly a follow up issue is ok

@@ -3490,6 +3490,7 @@ def _putmask_smart(v, m, n):

# we ignore ComplexWarning here
with warnings.catch_warnings(record=True):
warnings.simplefilter("ignore", np.ComplexWarning)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does the context manager restore all of the warnings filters after? (I guess that is the point?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's the idea. Ideally libraries shouldn't modify the global warnings registry without good cause.

@@ -175,23 +174,23 @@ def test_get_store(self):

class TestParser(object):

@pytest.mark.filterwarnings("ignore")
def test_deprecation_access_func(self):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should these actually be tm.assert_produces_warning(FutureWarning)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm I see your comment below

@@ -1134,19 +1175,22 @@ def test_ix_frame_align(self):
df = df_orig.copy()

with catch_warnings(record=True):
simplefilter("ignore", DeprecationWarning)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

grr....we should just remove all of this .ix bizness

@@ -508,30 +507,30 @@ def test_frame_multi_key_function_list():


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we could prob split the panel tests to a separate file (and just ignore warnings there), maybe make an issue

def epochs(request):
return request.param
@pytest.fixture(params=['timestamp', 'pydatetime', 'datetime64', 'str_1960'])
def epochs(epoch_1960, request):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add a doc-string

@@ -10,6 +10,9 @@
import pandas.util.testing as tm


ignore_ix = pytest.mark.filterwarnings("ignore:\\n.ix:DeprecationWarning")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe move this to the top-level conftest and use it above (a number of files where catching all of the ix warnings)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm do you know how to use marks defined in the top-level conftest.py? I'm not actually sure that's possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think you can just import it

@@ -388,52 +388,61 @@ def test_iloc_getitem_frame(self):

result = df.iloc[2]
with catch_warnings(record=True):
filterwarnings("ignore", "\\n.ix", DeprecationWarning)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use ignore_ix?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That filters the warning for the entire test. I was trying to exactly match the tests previous intent, of only filtering within the catch_warnings blocks.

@jreback
Copy link
Contributor

jreback commented Sep 18, 2018

@jreback can you clarify our current policy on "allowed failures"? I don't recall why they're in the allowed-failures section.

  • so numpy-dev is allowed to fail because there may be a change which breaks us but is not pushed to public (ideally would fail, except for when numpy / dateutil breaks things everything breaks and all builds would then fail)
  • slow tests are there just to make the build green faster
  • clipboard test uses to fail pretty unexpectedly
  • doc build takes a long time.

so they are really there to get a probable green faster. I don't really have a problem moving them to required builds actually.

@TomAugspurger
Copy link
Contributor Author

Thanks. So I think it's best to treat numpy / dateutil dev as "allowed failures" but as soon as we see a failure we should open an issue that would block the next release (and maybe report upstream if it looks like an unintentional break).

We might consider moving the doc build to azure. Apparently the workers more powerful than Travis.

@jreback
Copy link
Contributor

jreback commented Sep 18, 2018

Thanks. So I think it's best to treat numpy / dateutil dev as "allowed failures" but as soon as we see a failure we should open an issue that would block the next release (and maybe report upstream if it looks like an unintentional break).

yep, that's the idea

We might consider moving the doc build to azure. Apparently the workers more powerful than Travis.

certainly

@jreback
Copy link
Contributor

jreback commented Sep 18, 2018

@TomAugspurger merge when you are ready

* fixture docstrings
* linter fails
@TomAugspurger
Copy link
Contributor Author

👍 pushed some doc fixes. Will merge on green.

@TomAugspurger
Copy link
Contributor Author

Travis all passed. Merging.

@TomAugspurger TomAugspurger merged commit 1a12c41 into pandas-dev:master Sep 18, 2018
@TomAugspurger TomAugspurger deleted the pytest-warnings branch September 18, 2018 16:52
aeltanawy pushed a commit to aeltanawy/pandas that referenced this pull request Sep 20, 2018
Sup3rGeo pushed a commit to Sup3rGeo/pandas that referenced this pull request Oct 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Testing pandas testing functions or related to the test suite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants