Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for your contribution, we look forward to reviewing it!

FYI: rebased and changed it so that message is treated as regex too (as implied by the documentation).

The inaccurate statements (and invalid regex) in the docs resulted in multiple hours of frustration in spyder-ide/qtpy#296 (as well as previous PRs) as to why the documented approach to matching warnings by regexes in message and module didn't work, and rendered it impossible to precisely specify the desired warnings to enable and suppress. Is there something blocking this PR from being reviewed and merged to fix this defect?

Is there something blocking this PR from being reviewed and merged to fix this defect?

I'm assuming the main blocking factor is developer bandwidth.

By the way, while we're at it, would do you think about automatically appending (\..*)?\Z to the regex? This means that it will by default match against all submodules/subpackages of a package name that is matched by the user regex. This is the behaviour I would personally always prefer, and users could still counter this by simply appending $ to their regex, making it explicit that it should match the exact pattern. Currently it appends \Z and matches directly against the child module/package itself.

Good question; that would certainly be a more helpful behavior to me. However, if we're going to do that, I would suggest either just changing it to match the behavior of filterwarnings, which as far as I can tell from the code, doesn't have anything implicitly added to the pattern, or else changing filterwarnings to match this new behavior and clearly documenting it.

I'm not a core dev or anything, but especially if its decided to go ahead with the latter, as a user would be something I think might be worth a What's New entry, since it has non-trivial direct user impact and changes the behavior of the popular -W option, with potential backward compat impacts if users are relying on rare characters being escaped. Also, I think it would be worth adding a .. versionchanged block in the docs noting that -W's behavior was changed to allow regexes in the module field to match the behavior of filterwarnings, and that it wasn't the case before.

This changeset may introduce a new attack vector and a potential REDOS vulnerability.

@tiran Do you think it would be better to only fix the documentation then? Personally, I don't think that's a serious issue. There are more dangerous environment variables to attack around.

Personally, my preferred option would be to modify the behaviour of -W and PYTHONWARNINGS to be a literal match (so you don't have to escape the . as a user), but also match against submodules and subpackages. In that case, I assume that a full regex is rarely really needed.

Personally, my preferred option would be to modify the behaviour of -W and PYTHONWARNINGS to be a literal match (so you don't have to escape the . as a user), but also match against submodules and subpackages. In that case, I assume that a full regex is rarely really needed.

That would potentially work for modules without requiring full regex support or escaping for what I would imagine are a large majority of use cases, though it would make the syntax and behavior of -W and PYTHONWARNINGS inconsistent with that of filterwarnings, which could increase potential user confusion and subvert expectations unless they carefully read the docs. This also doesn't address the similar issues with message, where regex support is more critical, though the ability to match on substrings (which at least per my testing, doesn't appear to currently work) while escaping regex would address some user cases.

This changeset may introduce a new attack vector and a potential REDOS vulnerability.

Could you explain a little further as to the actual plausible attack scenario? As I understand it, typically ReDoS attacks involve inserting user input into vulnerable regexes, rather than manipulating regexes themselves. An attacker would have to already have control over the user/shell environment in which Python is running sufficient to set arbitrary environment variables in order to exploit this via the env var, which, generally speaking, would expose much more serious issues than this, I would think.

Also, this would need to be weighed against the risk of developing silencing valid warnings (including those that may result in a security or service impact) either unintentionally or necessarily due to the limited expressiveness without regexes.

Ok. At least the incorrect documentation seems to have been fixed at some point, no longer stating examples with (broken) regexes for PYTHONWARNINGS.

I'm going to close this, as there doesn't seem to be any upstream capacity to deal with this if received as thirdparty PR.

Edit: Actually, the documentation is still broken in parts, but I'll leave that to you.

Its rather disappointing that this was summarily closed and the branch deleted after substantial discussion, given as explained this is a pretty serious limitation that results in substantially over-broad warning silencing, the proposed alternate approach would avoid the potential complexity and security issues raised, and in practice this makes potentially noisy but useful warnings, like -X warn_default_encoding from being used in many cases.

I will leave this here, where we basically came to the same conclusion that the current -W flag is too limited to be useful in some cases.

https://discuss.python.org/t/how-to-filter-pipdeprecationwarning/21571/1