Indentation checkers should not be active on code inside triple-quotes #45
Comments
|
I've tested it, and it only reported 2 issues related to tabs It did not check the indentation level, just the presence of at the beginning of the lines. |
Yes. This input should not produce any errors or warnings: message = """The next line starts with <tab> and then <space>
but that's fine by pep8
since this is inside a string."""
print messagebut pep8 shows I am working with code that is PEP8 clean by now but still makes pep8 throw a ton of false positives of that very kind. Please fix it. Many thanks! |
|
I agree this should probably not raise a warning. (or it should be an option) As a workaround, you can put |
And if you want the string to only use so many spaces for tab, you can use message = "Tab\ttab" # -> "Tab tab"
message = "Tab\ttab".expandtabs(3) # -> "Tab tab" |
|
Would this be fixed by muting the leading spaces in strings (in physical lines)? (I say leading spaces only because I think (invisible) trailing spaces should be flagged no matter the context). |
|
I fail to understand that muting idea of yours. Could you give an example or explain in more detail? On trailing whitespace: keep in mind that there are languages that use trailing spaces to encoding forced newlines. markdown or something, not sure which one. If you have such a document inline in python code, you'd change it's meaning. |
|
Muting as in treating the spaces as some non-space character. See mute_string() in the pep8 source code for details. It is already doing something like this for "logical" lines. According to PEP 8, "Don't write string literals that rely on significant trailing whitespace. Such trailing whitespace is visually indistinguishable and some editors (or more recently, reindent.py) will trim them.". |
|
I absolutely agree that trailing whitespace is evil but keeping code execution untouched goes first, in my eyes.
|
|
Reason for me not to use Markdown then :). I guess the Whitespace programming language is another example. This isn't pointed at you of course, but a programmer relying on trailing whitespace and using pep8's W291 option seems a bit masochistic to me. |
|
Maybe better let's concentrate on a solution (or a workaround at least) :-) I suppose something like this could work but may need more thinking:
I'd be happy to help with the string regex iterator. Any ideas how to solve the indentation-line-number problem? |
|
This just bit me because I have a string literal that contains a line with blank space, used to match blank space within a file generated by another tool. |
|
I think this bug can be summarised as: "physical checks run on (multiline) strings". |
|
I would disagree that trailing whitespace should still be checked by pep8 even in multiline string literals. What if you need to make a string comparison of some input that contains whitespace trailing lines? Having to manipulate the input just to make it so that it can be compared to a mutilated (because of "coding standards") string literal is simply wrong. |
|
@brianjmurrell, then use |
|
@myint, but that disables that check for the whole file, or whole project of files if you are checking more than one. That's throwing the baby out with the bathwater. Seriously, is it so unreasonable to consider that a string literal is a literal string and not presume that it's got python code in it? |
|
@brianjmurrell, I think a possible solution would be to break I personally consider the whole point of the original |
|
With |
Is it workaround, or final solution? I would like to use docstrings for documentation purposes, and I want to have whitespaces, tabulation and other stuff there, out of the box, without sane limitations. Currently it is looks like For example, I want to place markdown into docstrings, bcz doc-parser supports it, and I like it. But BTW: PyCharm can not remove trailing whitespaces in docstrings automagically. It requires some tunings/dancing/virgin-blood/moonlight to provide this functionality. Sad, because people told, that PyCharm - is a decent IDE for python.. |
It is something you can use today. So in a way it's both.
I disagree, but that's my opinion.
That's unfortunate
That's surprising and disappointing but not relevant here. |
|
@sigmavirus24 thank you for reply. I will cry and eat this cactus )) |
@sigmavirus24 Could you please clarify resolution on this issue? |
|
pycodestyle has a longstanding bug/limitation whereby tabs inside of
triple-quote strings are counted as W191 ("indentation contains tabs").
PyCQA/pycodestyle#45
Strictly speaking, that's not a violation of PEP8, but as several
commentators note, using tabs inside of string literals means that, if
your editor doesn't show the distinction, it might not be clear what the
intent is.
Let's avoid both problems and use \t instead.
pycodestyle has a longstanding bug/limitation whereby tabs inside of
triple-quote strings are counted as W191 ("indentation contains tabs").
PyCQA/pycodestyle#45
Strictly speaking, that's not a violation of PEP8, but as several
commentators note, using tabs inside of string literals means that, if
your editor doesn't show the distinction, it might not be clear what the
intent is.
Let's avoid both problems and use \t instead.
pycodestyle has a longstanding bug/limitation whereby tabs inside of
triple-quote strings are counted as W191 ("indentation contains tabs").
PyCQA/pycodestyle#45
Strictly speaking, that's not a violation of PEP8, but as several
commentators note, using tabs inside of string literals means that, if
your editor doesn't show the distinction, it might not be clear what the
intent is.
Let's avoid both problems and use \t instead.
|
Is the intention to keep this behavior or "fix" it? Where should the |
If I have a multi-line string (in triple quotes), I don't believe that pep8 should be analyzing the contents for indentation problems and the like. This code may very well be not-python and, as such, need not comply to pep8. It might be nice (though I am not certain of how easy) to treat docstrings different from other block quotes as there are guidelines on docstrings in PEP 257: http://www.python.org/dev/peps/pep-0257/
The text was updated successfully, but these errors were encountered: