| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
This may look unrelated, but comparing these as strings means a proper diff gets printed when the test fails (and it was this test that picked up the problem with the non-regex entry in the internal filter list).
Sorry, something went wrong.
|
@brettcannon Something I noticed while making this, is that we don't currently have a test that ensures the C level filter initialisation is consistent with the Python level default filter initialisation at https://github.com/python/cpython/blob/3.6/Lib/warnings.py#L506 I'm thinking this may be a good opportunity to address that, by adding a variant of the test added by the PR that forces the subprocess to reload the Python warnings module without the C accelerator module before printing the contents of the filter list. |
Sorry, something went wrong.
|
It's also suspicious that ./python -m test test_warnings passed, even though I hadn't fixed this line yet: https://github.com/python/cpython/blob/3.6/Lib/warnings.py#L344 (similar to the changed C code in the PR, those lines assume that the module name is always either None or a compiled regex object - no strings allowed) |
Sorry, something went wrong.
|
It would probably be easier to refactor that code into a function so that you can write a test which tracks what changed in Python prior to launching. |
Sorry, something went wrong.
- primary change is to add a new default filter entry for 'default::DeprecationWarning:__main__' - secondary change is an internal one to cope with plain strings in the warning module's internal filter list (this avoids the need to create a compiled regex object early on during interpreter startup)
While CPython doesn't implicitly import `warnings` at startup, some other implementations might do so. Explicitly clearing the module cache ensures the subprocess also gets the pure Python version, no matter what.
|
I worked out why the new test was passing even though I hadn't updated the pure Python implementation: the pure Python version wasn't configuring the new __main__ filter at all, and the tests were instead checking the C accelerated implementation twice. So I've tweaked that test case to make sure that the subprocess uses the pure Python implementation when that's the version being tested (unlike the C accelerated version, it uses a regex like normal, since it uses the public module API to add the filters). I've also updated the test case to account for the empty default filter list in Py_DEBUG builds. The PR has been rebased on the current master branch, and I've fixed the issue reference to point to the right place. |
Sorry, something went wrong.
|
The Windows failure looks like it's just due to the fact I'm not using universal newlines mode when reading data from the subprocess, so the Windows line endings are confusing matters. |
Sorry, something went wrong.
|
@vstinner @brettcannon OK, I think this should be ready for review now - I think I've covered all the doc updates I proposed in the PEP (with a few other cleanups along the way), and the last commit will hopefully fix the line ending problem on Windows. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
default::DeprecationWarning:__main__
strings in the warning module's internal filter list
(this avoids the need to create a compiled regex object
early on during interpreter startup)
https://bugs.python.org/issue31975