Add error D303 when an f-string is used as a docstring #381
Conversation
|
Tests are green locally under 3.5-3.7 except for the stemming issue that #379 addresses. |
|
Thanks a lot, @lordmauve! I rely on this change in wemake-services/wemake-python-styleguide#579 |
|
@Nurdok friendly ping. What are the steps to get this merged? Some of my users rely on this fix: wemake-services/wemake-python-styleguide#579 |
lordmauve
force-pushed
the
fstrings
branch
2 times, most recently
from
417d67d
to
c1d5da2
Compare
|
Grr, I suck at git, trying to get this rebased and mergable... I don't know where 14a59e6 came from. |
|
Ok, I think that's clean |
|
Tests are now failing because mypy returns an error when it sees fstrings under Python 3.5, even though the file won't be imported under Python 3.5, and it appears impossible to tell mypy to ignore this. Looking for a workaround. |
|
|
|
That does not work; mypy continues to parse the file and raise the error. |
|
Sorry for the long delays in response - I've been on back-to-back family vacation and business trips. I'll to catch up as soon as I can. |
|
@lordmauve any updates on this? |
|
Closing this as it has been inactive for a while. Please feel free to re-open if this is still relevant. |
samj1912
added
the
STALE-PR
samj1912
force-pushed
the
fstrings
branch
3 times, most recently
from
c674d84
to
8a97078
Compare
samj1912
removed
the
STALE-PR
samj1912
force-pushed
the
fstrings
branch
3 times, most recently
from
b250f92
to
ab164eb
Compare
|
@Nurdok please take a look when you have time - I make the code more resilient to fstrings in case people ignore it even after the warnings. |
samj1912
force-pushed
the
fstrings
branch
2 times, most recently
from
2e15429
to
9afb712
Compare
|
@Nurdok will you have a chance to look at this? It LGTM but waiting on your review. |
| return sorted(all, key=lambda this_check: not this_check._terminal) | ||
|
|
||
| # Note - this needs to be listed before other checks | ||
| # as f string evalutaion may cause malformed AST Nodes. |
There was a problem hiding this comment.
Nit - other comments spell this out as "f-string". Please add a hyphen here as well.
|
|
||
| f-strings are not treated as string literals, but they look similar | ||
| and users may attempt to use them as docstrings. This is an | ||
| outright mistake so we issue a specific error code. |
There was a problem hiding this comment.
This text will be emitted when running with --explain, so it should explain the problem with the code. The current description seems more "internal" in phrasing. How about this?
"""D303: Docstring may not be f-strings.
f-strings are not treated as string literals by the Python interpreter and are not parsed as docstrings.
"""
(trim to appropriate line length)
| # If the docstring is a fstring, it is | ||
| # not considered a valid docstring. See | ||
| # https://bugs.python.org/issue28739 | ||
| raise ParseError( |
There was a problem hiding this comment.
Mistakenly using an f-string for a docstring does not cause a syntax error, so we shouldn't raise a ParseError here.
Instead, I suggest we rename this as eval_docstring and just return an empty string if we find an f-string.
| return sorted(all, key=lambda this_check: not this_check._terminal) | ||
|
|
||
| # Note - this needs to be listed before other checks |
There was a problem hiding this comment.
Checks should not rely on order, other checker functions, etc. Let's find a better solution.
Perhaps my suggestion for returning an empty string from eval_docstring is enough to solve this. Otherwise, we can have it return None and do more verbose checks at call sites. LMKWYT.
Emit a new error code D303 when an f-string is found where a docstring is expected.
Fixes #368.