-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Fix testing with tests.py on Py3.6. #8281
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
Invoking `tests.py` used to fail on Py3.6 due to the use of deprecated invalid escapes both in the codebase and in third-party code (dateutil). Fix the codebase, skip the checks on dateutil. It is strange (and should be worth investigating...) that the CI did not fail before, as it also uses `tests.py` on Py3.6...
I have also not been seeing these failures, and have been testing using tests.py + py3.6 for a while now... |
@@ -94,12 +94,6 @@ def test_too_many_date_ticks(): | |||
# setting equal datetimes triggers and expander call in | |||
# transforms.nonsingular which results in too many ticks in the | |||
# DayLocator. This should trigger a Locator.MAXTICKS RuntimeError | |||
warnings.filterwarnings( |
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.
Does this warning not come out of singular dates anymore?
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.
Nope (that's why the tests pass :-)).
Do you get a warning if you do Do you get an error on one of the escape sequences I fixed if you install the filter as in |
I can confirm that on a fresh install of python 3.6 there are a lot of escaped characters errors, which are fixed by this PR. |
with arch system python:
and |
woot
|
I am even more confused now... |
|
|
Anything in |
Nope, I can get the warning via:
|
Ah, I found it. If you do e.g. I guess this is because the warning is only triggered at byte-compilation time, which only occurs if the mtime of the .py is more recent than the mtime of the .pyc -- which is not the case when you install from the package manager, but is the case after my change (and then it was always going to stay like that, as python did not have the rights to rewrite the pyc, so it had to re-byte-compile every time). |
That does make sense. It is re-assuring that the interpreter is, as usual, correct. |
@@ -14,15 +14,16 @@ | |||
|
|||
if __name__ == '__main__': | |||
|
|||
import dateutil.parser |
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 good to get rid of these in Matplotlib itself, but it's hacks like these that make me a bit wary to keep this test setup around. Maybe when we figure out the cron jobs, we can run this on a nightly build or something.
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.
FWIW I think this test really belongs in something like pycodestyle.
Invoking
tests.py
used to fail on Py3.6 due to the use of deprecatedinvalid escapes both in the codebase and in third-party code (dateutil).
Fix the codebase, skip the checks on dateutil.
It is strange (and should be worth investigating...) that the CI did not
fail before, as it also uses
tests.py
on Py3.6...xref #8271.