Skip to content

Conversation

@blueyed
Copy link
Contributor

@blueyed blueyed commented Nov 17, 2018

Do not cause a SyntaxError for something like:

DeprecationWarning: invalid escape sequence \w

This was happening via pdb++ when it imported pygments (and that had no
compiled .pyc file).

Do not cause a SyntaxError for something like:

> DeprecationWarning: invalid escape sequence \w

This was happening via pdb++ when it imported pygments (and that had no
compiled .pyc file).
Copy link
Member

@RonnyPfannschmidt RonnyPfannschmidt left a comment

Choose a reason for hiding this comment

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

its reasonable to make those normal warnings instead of warnings as we have no controll over external packages

as a follow-up we should investigate if we can keep the error for pytest and its own tests

@blueyed blueyed merged commit 7f990e2 into pytest-dev:master Nov 17, 2018
@blueyed blueyed deleted the default-invalid-escape-sequence branch November 17, 2018 19:08
@blueyed
Copy link
Contributor Author

blueyed commented Nov 17, 2018

We could use the following:

error:invalid escape sequence:DeprecationWarning:^((?![/\]pytest[/\]).)*$

But this matches through the path only (module file name), and would still throw errors from packages in .venv/… then.

A warnings filter function could be used to make use of os.path.dirname(_pytest.__file__) etc, but that would still match anything before pytest's warnings system kicks in itself anyway.

Merging as-is for now.

@asottile
Copy link
Member

we don't have to worry for pytest itself either as pyupgrade will just fix invalid ones :)

@RonnyPfannschmidt
Copy link
Member

@asottile good point - we still have some acceptance testing patters where we use strings in strings and might miss one that would show up in a test tho

@blueyed main reason i proposed this as a follow-up is that i believe the solution to mark those down correctly might not come easy and we migh even have to decide this one is way too tricky to be worth it

and given the point @asottile made we should naturally approach the lack of need of this check sooner or later anyway - so i propose we let it go and fix the practices around code examples in tests to support better analysis from tools over time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants