Ask Your Question

Comment/Uncomment behavior

asked 2019-09-20 09:09:31 -0500

Michael's avatar

updated 2019-09-20 09:19:19 -0500

I have a piece of code

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

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

But by pressing Ctrl-Sa spurious indendation appears after completion

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

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)
# abs

but not in the following assignment case

#converter = Converter()
#converter.setValidFilenameMask(VALID_EXTENSIONS, MASKED_SUFFIXES)
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-09-20 09:19:00 -0500

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.

edit flag offensive delete link more


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 -0500 )edit

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 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2019-09-20 09:09:31 -0500

Seen: 5,383 times

Last updated: Sep 20 '19