bpo-31975 (PEP 565): Show DeprecationWarning in __main__

[ncoghlan]

• 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)

https://bugs.python.org/issue31975

[ncoghlan]

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).

[ncoghlan]

@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.

[ncoghlan]

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)

[brettcannon]

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.

[ncoghlan]

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.

[ncoghlan]

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.

[ncoghlan]

@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.