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

Closed
posborne opened this Issue Dec 29, 2011 · 21 comments

Comments

Projects
None yet
10 participants

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/

Contributor

florentx commented Mar 25, 2012

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 commented May 3, 2012

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!

Contributor

florentx commented May 23, 2012

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.

Owner

sigmavirus24 commented May 23, 2012

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

myint commented Jul 1, 2012

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 commented Jul 1, 2012

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.

Member

myint commented Jul 1, 2012

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 commented Jul 2, 2012

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.

Member

myint commented Jul 2, 2012

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 commented Jul 2, 2012

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?

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 commented May 27, 2013

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

@sn6uv sn6uv added a commit to sn6uv/pep8 that referenced this issue May 27, 2013

@sn6uv sn6uv dont run physical checks within string fixes #45 25701cf

@sn6uv sn6uv added a commit to sn6uv/pep8 that referenced this issue May 27, 2013

@sn6uv sn6uv dont run physical checks within string fixes #45 e71fef8
Contributor

gward commented Nov 24, 2013

Whoops, I opened #242 without noticing this one. And then I went ahead and implemented a fix for #242 and #224: see jcrocholl#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.

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.

Member

myint commented Nov 29, 2013

@brianjmurrell, then use --disable=W291.

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

Member

myint commented Nov 29, 2013

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

Jorge-C referenced this issue in biocore/scikit-bio Feb 7, 2014

Closed

Some whitespace cleanup #85

florentx added this to the 1.4.x milestone Mar 24, 2014

florentx removed the needs patch label Mar 25, 2014

Contributor

florentx commented Mar 26, 2014

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

florentx closed this Mar 26, 2014

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

Owner

sigmavirus24 commented May 18, 2017

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.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment