Ask Your Question
1

Comment/Uncomment behavior

I have a piece of code

if __name__ == '__main__':
  converter = Converter()
  converter.setValidFilenameMask(VALID_EXTENSIONS, MASKED_SUFFIXES)
  converter.run(RESOLUTION)

  # more code here (no comment though, by the way)

After commenting out some code (whether manually or by selection and using 'comment out'), everything seems to be in order

#converter = Converter()
#converter.setValidFilenameMask(VALID_EXTENSIONS, MASKED_SUFFIXES)
#converter.run(RESOLUTION)

But by pressing Ctrl-Sa spurious indendation appears after completion

#converter = Converter()
#converter.setValidFilenameMask(VALID_EXTENSIONS, MASKED_SUFFIXES)
# converter.run(RESOLUTION)

This seems to depend on content, because it also happens after adding a line 'abs' before commenting out

#converter = Converter()
#converter.setValidFilenameMask(VALID_EXTENSIONS, MASKED_SUFFIXES)
# converter.run(RESOLUTION)
# abs

but not in the following assignment case 

#converter = Converter()
#converter.setValidFilenameMask(VALID_EXTENSIONS, MASKED_SUFFIXES)
# converter.run(RESOLUTION)
#n=23
Michael's avatar
171
Michael
asked 2019-09-20 09:09:31 -0600
Wingware Support's avatar
4.2k
Wingware Support
updated 2019-09-20 09:19:19 -0600
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

I suspect you have pep 8 reformatting enabled in the Editor > PEP 8 preference area. It looks like it might be running a pep8 format, although I'd expect spaces before all the comments (but then autopep8 can be a bit weird).

If that is the case it may be that unchecking the Editor > PEP 8 > Spaces After # preference will solve it.

If that's not it, please let me know.

Wingware Support's avatar
4.2k
Wingware Support
answered 2019-09-20 09:19:00 -0600
edit flag offensive 0 remove flag delete link
more

Comments

unchecking the Editor > PEP 8 > Spaces After #

That solves the problem. Is it caused by the PEP8 spec or an error / too smart behavior of the IDE, because you mentioned the expected 'spaces after all comment signs' (in general I like it that way and would not refuse an autocorrection)?

Michael's avatar Michael (2019-09-20 09:31:53 -0600) edit
more
  • delete

It's a bug or quirk in autopep8, which is what we're using to do this reformatting. When the "spaces after #" pref is unchecked then we tell autopep8 to ignore E26 and E265. I suspect it's trying to decide whether the contents of the comment are code or not, and failing. It may be trying to avoid adding spaces when it's code to not break comment out/in functionality, but I'm not sure. We're adding support for Black and YAPF reformatting in Wing 7.2, which maybe will be a way to solve this. Those are more rigid reformatters while autopep8's philosophy is to first see if it thinks there is a pep8 violation and be lax about anything it thinks isn't one, so the results are not as consistent.

Wingware Support's avatar Wingware Support (2019-09-20 09:49:34 -0600) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer