-
Notifications
You must be signed in to change notification settings - Fork 109
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
B018 wrongly detects inline variable or attribute docstrings #208
Comments
Can confirm. |
Can confirm, too. You may see a failing Github Action run here: https://github.com/Mischback/django-calingen/actions/runs/1514981629
The full As
The full |
Release 21.11.28 of flake8-bugbear introduces a bug with B018 (see PyCQA/flake8-bugbear#208). As of now, simply disable that rule in flake8 configuration.
B018 is also triggered for multi-line strings that are used as a comment aside from docstrings. Is this behaviour intentional? |
For info, attribute docstrings aren't a Python feature, however, are widely used and supported by the Sphinx documentation system via autodoc. |
Damn. Sorry all, definitely missed this and it's not intended. A PR adding a unit test showing we no longer flag this will definitely be accepted. I'll try get to it but welcome to beat me to it! cc: @kasium - Checks creator to see if they can workout a fix quicker than I :D |
* chore: adopt NEP-0029 for py version deprecation policy fixes #4560 * chore: drop py3.6 from CI * docs: add news item * fix: failing qa because latest version to flake8-bugbear see PyCQA/flake8-bugbear#208 * chore: require >=py3.7
@cooperlees I'm very sorry for that. As a fast workaround, let's just skip strings and work with anything else. Then we can look for a better solution |
Hi all. I created #209 |
21.11.29 released reverting checking of strings for now. We will work on adding some pattern matching support into the string detection and probably default to ignoring this edge use case. I also, 21.11.28 yanked from PyPI so it can not be installed to create noise. |
Wow, that was quick! PyCQA/flake8-bugbear#208 already fixed!
Wow, that was fast! @cooperlees @kasium Thx a lot! |
Unwanted CI noise is the worst so I didn’t want us to help create it. This needs more thought and this will give us time rather than rushing out something. |
PyCQA/flake8-bugbear#208 Change-Id: Ifc3854032ea6f6144e22830dfaf4a4d83f564d4a
@cooperlees the issue is, that the used quotes (""" or " or ') are not accessible in the AST. Therefore we need to use tokens. Since it's used for docstrings even in the middle of code, I would suggest to keep strings out. If it's fine for you, I would enhance the tests, code and README to reflect it. |
So you think there's not way to look at the string contents themselves by keywords or regex to try reduce the noise and reenable string? I was thinking of (worst case) a way for people to specify from regex's and have some defaults ... |
I think that this is somehow error prone. What's possible is, to only allow this pattern in certain cases, e.g. on module level and in __init__ methods. So, e.g. in the middle of a custom function such a string makes no sense. However, some users use multiline strings as comments... |
Personally, I use
I think this is bad behaviour and can and should be marked by the corresponding rule, perhaps even with the hint to use |
I am hitting this issue for format strings used as attribute docstrings. Note that attribute docstrings are listed as an official convention in PEP 257.
Here is a false positive: from dataclasses import dataclass
x = 0
@dataclass
class Foo:
bar: int
f"""Attribute docstring {x}""" Output:
@cooperlees Do format string checks need to be temporarily rolled back too? Environment
|
My fault. The ignore was only for strings and not for f-strings (aka JoinedStr). PR is open |
Having an inline attribute doc string or a module variable docstring, it is wrongly marked as B018 (sample from sphinx doc):
The text was updated successfully, but these errors were encountered: