Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

autopep8 0.6 corrupts multi-line string content #12

Closed
hartwork opened this Issue · 7 comments

2 participants

@hartwork

Consider this tiny program:

text = """line one
    line two indented by <tab>
  line three indented by <space><space>
line four"""
lines = text.split('\n')
text = '\n'.join('>' + l for l in lines)
print text
print 'length:', len(text)

When run it produces this output:

# python multiline-string.py 
>line one
>   line two indented by <tab>
>  line three indented by <space><space>
>line four
length: 90

After running it through autopep8 0.6 the output changes to:

# python multiline-string.py 
>line one
>        line two indented by <tab>
>  line three indented by <space><space>
>line four
length: 97

as <tab> has been changed to 8*<space>.

To be fair, pep8 is broken in that regard, too:

# pep8 multiline-string.py 
multiline-string.py:2:1: W191 indentation contains tabs
multiline-string.py:3:1: E101 indentation contains mixed spaces and tabs
@hartwork

PS: 0.5.2 is not affected

@myint
Collaborator

You should probably contact pep8's developers. autopep8 basically assumes pep8's reports to be correct (for the most part).

Though, personally, I prefer to just remove all trailing whitespace in my code.

@myint
Collaborator

You probably already know this, but you can set autopep8 to ignore those errors (globally) for now.

$ autopep8 --ignore=W191,W101,W291
@hartwork

You should probably contact pep8's developers

There is a related bug report for pep8: jcrocholl/pep8#45

You probably already know this, but you can set autopep8 to ignore those errors (globally) for now.

Unfortunately, that's less than a workaround. For one because the code does not have pep8 errors and two because I then miss other fixes for related issues that I might be interested in.

@myint
Collaborator

I just realized you weren't talking about trailing whitespace. (I thought the <tab> and <space> were in their actual location at the end of the lines. That would violate one of the PEP 8 rules.) In that case, I do agree. pep8 could probably mark the multi-line string lines before running the normal checks.

@myint
Collaborator

eb47d25 is a partial solution.

@myint
Collaborator

Fixed with 594b73b. Let me know if I missed any cases.

@myint myint closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.