Python console: not pep8 compliant...

[Zolko]

That level of consistency is probably a pipe dream. In almost all Draft files ...

Consistency could also be seen as an objective. Unfortunately, the Draft workbench was "refactored" by someone who did it all wrong, and then left. Yet, I do think that having a coherent – and elegant – coding style, and also similar file structure across WBs, is important for long-term maintenance of the whole FreeCAD project. Look at orphaned WBs: when the sole developers looses interest, it's finished, and lost.

[Roy_043]

I am obviously not against consistency, provided it is a means to an end. But asking, inexperienced, programmers to make (PEP8) consistent edits in files that are not, is somewhat problematic. People always take some of their cues from what is already there.

[chennes]

As you suggest, this is basically a lost cause anyway, unless we use a tool to enforce the style. It only caught reviewers' eyes because GitHub shows the character change very clearly, and we saw a change from what appeared to be at least a locally-consistent use to a mixed use and thought "why make that change?"

So, all that said, I've merged the PR in question...

[Roy_043]

what appeared to be at least a locally-consistent use to a mixed use

You have to look again and more carefully please! The original file showed the mixed single and double quotes when defining these dictionaries (see example below). You will find that in more Draft files (copy-pasted from the same example file probably). I thought that this mixed use was peculiar and changed it to single quotes (consistently for the edited dictionaries). This was then criticized, and I subsequently changed the single quotes to double quotes (again only for the edited dictionaries). But after this 2nd edit the files in question still use a mix of single and double quotes...

Example of a dictionary before my edits:

Code: Select all

        return {'Pixmap': 'Draft_BezCurve',
                'Accel': "B, Z",
                'MenuText': QT_TRANSLATE_NOOP("Draft_BezCurve", "Bezier curve"),
                'ToolTip': QT_TRANSLATE_NOOP("Draft_BezCurve", "Creates an N-degree Bezier curve. The more points you pick, the higher the degree.\nCTRL to snap, SHIFT to constrain.")}

[sliptonic]

"Practicality beats purity"

I don't care about any particular standard but I find a lot of practical value in using Black:

First, it won't run if the code isn't syntactically valid so that's a good check.
Second, I've had to resolve merge conflicts that were really nasty with lots of white space changes. Running black on both branches and squashing them makes it obvious what changes are relevant and which are just formatting.

Finally, because of how Black breaks long lines:
- a side by side diff view, especially three-panel merge conflict resolution fits on a 1920x1080 monitor comfortably so you can see conflicts without horizontal scrolling.
- A 1920x1080 screen in portrait mode allows editing a file with comfort.
- copied text pasted into a forum post or documentation is readable, again without horizontal scrolling