parser: Use #-space-% to allow writing PEP8-compliant Python code

[wenzeslaus]

Accept '# %' in parser script header definition because '#%' is against PEP8
(each line of a block comment starts with a # and a single space).

'#%' is still supported and documented as backwards compatibility.

All documentation and generated code uses the new '# %'.

[wenzeslaus]

Review by commits. Most relevant is 9cfc7c0.

[wenzeslaus]

Notably, the first commit in the series works as is without the other three. The first three are reported as failed only because Travis is set to end if there is a new commit on the branch.

[ninsbl]

Sound like a reasonable change to me. Good to able to activate all (or at least more) flake8 checks!

Given the number of files changed files, I did not go through all of them, but I could not find any issues in the visible I looked at (pluss some additional where i loaded the diff) and tests are passing. Neither did I find any cases where # % has been in the python code base before, so the change should be safe.
In the light of the extent of changes, maybe pop a note to grass-dev list and point to this PR? If no one objects within two days you merge?

[neteler]

I'd like to backport this great PR, any objections? Needed in terms of compatibility to write "modern-style" addons...

[wenzeslaus]

I guess one could consider being forced to break basic PEP8 rules a bug. Since both core and addon modules work, I think the change matured enough. However, backporting just the g.parser part (general/g.parser/main.c) seems to me better than changing all 150+ files in a patch release. I would prepare a PR for that. What do you think?

[neteler]

Yes, the backport of just the g.parser part would be nice.

[wenzeslaus]

the backport of just the g.parser part would be nice.

Done in #1446. Please, let me know there if that's what you had in mind.

[neteler]

the backport of just the g.parser part would be nice.

Done in #1446. Please, let me know there if that's what you had in mind.

Yes, exactly that - thanks.

[HuidaeCho]

@wenzeslaus I'm writing a new module and it's honestly pain to have to type all these extra spaces when defining options and flags because I need to type #-space-%-space-key:-space-name a lot. I tried black, but it didn't add spaces for me. Am I missing any black configs? For now, I use vim mapping. https://unix.stackexchange.com/a/343043, but this is not ideal because any hash will add a space even within code (e.g., strings).

[wenzeslaus]

@wenzeslaus I'm writing a new module and it's honestly pain to have to type all these extra spaces when defining options and flags because I need to type #-space-%-space-key:-space-name a lot.

Let's have this discussion on grass-dev. Perhaps you can continue this thread:

[GRASS-dev] Python and script header definitions for modules
https://lists.osgeo.org/pipermail/grass-dev/2021-April/095098.html

I tried black, but it didn't add spaces for me. Am I missing any black configs?

I think it leaves comments which look too complicated, i.e., could mean be else than a plain sentence, which is correct, just not desired here. (Well, that's at least my guess just based on experience.)

For now, I use vim mapping.

I suggest vi, that's one less character to type. ;-) An old joke I guess...

[HuidaeCho]

I suggest vi, that's one less character to type. ;-)

Technical correctness? In the end, we're forced to type one more space, so I didn't mind the extra "m", ;-)