Indentation checkers should not be active on code inside triple-quotes

[pycqa]

Indentation checkers should not be active on code inside triple-quotes

[florentx]

With pep8 1.5 you achieve it adding # noqa on the last line of the docstring.

[florentx]

I've tested it, and it only reported 2 issues related to tabs
test.py:4:1: W191 indentation contains tabs
test.py:4:1: E101 indentation contains mixed spaces and tabs

It did not check the indentation level, just the presence of at the beginning of the lines.
Does it need a fix?

[hartwork]

Does it need a fix?

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 message

but pep8 shows

pep8-trouble.py:2:1: W191 indentation contains tabs
pep8-trouble.py:2:2: E101 indentation contains mixed spaces and tabs

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!

[florentx]

I agree this should probably not raise a warning. (or it should be an option)

As a workaround, you can put \t inside the string to represent a tab.

[sigmavirus24]

As a workaround, you can put \t inside the string to represent a tab.

And if you want the string to only use so many spaces for tab, you can use expandtabs() on a string if you don't already know, e.g.,

message = "Tab\ttab"   # -> "Tab        tab"
message = "Tab\ttab".expandtabs(3)  # -> "Tab   tab"

[myint]

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).

[hartwork]

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.

[myint]

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.".

[hartwork]

I absolutely agree that trailing whitespace is evil but keeping code execution untouched goes first, in my eyes.
My guess on markdown seems to be right. From http://daringfireball.net/projects/markdown/syntax/#p :

When you do want to insert a
break tag using Markdown, you end a line with two or more spaces, then type return.

[myint]

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.

[hartwork]

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:

• Make a Python string regex iterator (properly finding 'foo', "foo" and """foo""" including escaped quote chars inside)
• Preprocess a file using that iterator substituting """foo""" and friends by "autopep8:<number>" \ "line 2" \ "line 3" ... to keep the number of lines unchanged. Indentation could be a problem.
• Run the usual internal processing
• Substitute those "autopep8:<number>" ... sections back to their original state

I'd be happy to help with the string regex iterator. Any ideas how to solve the indentation-line-number problem?

[fudomunro]

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.

[sn6uv]

I think this bug can be summarised as: "physical checks run on (multiline) strings".

[gward]

Whoops, I opened #242 without noticing this one. And then I went ahead and implemented a fix for #242 and #224: see #243. Pretty sure my pull request will work for this issue too; you just have to add "# noqa" after the multiline string that pep8 is complaining about.

[brianjmurrell]

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.

[myint]

@brianjmurrell, then use --disable=W291.

[brianjmurrell]

@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?

[myint]

@brianjmurrell, I think a possible solution would be to break W291 into two separate warnings. That way people can customize things accordingly. That has been the pattern for previous controversial warnings.

I personally consider the whole point of the original W291 to warn about trailing whitespace in all cases. The reason being the one I mentioned above and that is in the PEP 8 itself "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.".

[maxkoryukov]

@florentx @myint

# noqa on the last line of the docstring.

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 pep8 poke its nose in where it didn't belong (IMO).

For example, I want to place markdown into docstrings, bcz doc-parser supports it, and I like it. But flake8 raise an issue on my docstrings, because there are trailing whitespaces (they are required in my cases)

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..

[sigmavirus24]

Is it workaround, or final solution?

It is something you can use today. So in a way it's both.

Currently it is looks like pep8 poke its nose in where it didn't belong (IMO).

I disagree, but that's my opinion.

there are trailing whitespaces (they are required in my cases)

That's unfortunate

BTW: PyCharm can not remove trailing whitespaces in docstrings automagically.

That's surprising and disappointing but not relevant here.

[maxkoryukov]

@sigmavirus24 thank you for reply. I will cry and eat this cactus ))

[gyermolenko]

Is it workaround, or final solution?

It is something you can use today. So in a way it's both.

@sigmavirus24 Could you please clarify resolution on this issue?
Personally I can't understand why it is closed (just my opinion, no hard feelings)

[sigmavirus24]

Is it workaround, or final solution?

It is something you can use today. So in a way it's both.

Could you please clarify resolution on this issue?

• # noqa will continue to skip this warning. (hence the joke about finality)
• # noqa support was added providing an escape hatch for folks who want to opt out of this behaviour
• Florent was quite explicit that at the time of their writing, this was not okay per PEP-0008. I haven't bothered to confirm that it still is given the infuriating fluidity of that document (revisions days apart will conflict). And this tool serves, to the best of its ability, provide checks that hold to the document. So, in a way, at the time of implementation this was the correct behaviour provided the mission statement of the tool. It may no longer be and we can open a new issue to track that and potentially fix it.

[kaddkaka]

Is the intention to keep this behavior or "fix" it? Where should the #noqa magical comment be but? I'm not a fan of #noqa since it's a short abbreviation and without prior knowledge it's hard to know what it is.