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

[posborne]

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/

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