Python console: not pep8 compliant...

[Roy_043]

As an inexperienced Python programmer I frequently consult the Python console. Sadly much of the code I see there is not pep8 compliant.

Example:

Code: Select all

Gui.runCommand('Draft_Line',0)

According to the comments on two of my recent PRs this should be:

Code: Select all

Gui.runCommand("Draft_Line", 0)

Double quotes and a space after the comma.

There is also this:

Code: Select all

>>> str = "abc"
>>> str
'abc'

It would be nice if the Python console were to set the right example here.

[openBrain]

https://www.python.org/dev/peps/pep-0008/#string-quotes

[Roy_043]

Then I don't understand this comment:
https://github.com/FreeCAD/FreeCAD/pull ... r792673896

[openBrain]

Then I don't understand this comment:
https://github.com/FreeCAD/FreeCAD/pull ... r792673896

It's partly wrong. Then true ideally a file (if possible a project) should be consistent.
I have a rule of thumb that is :
* Double quotes for "human" strings : strings that will be exposed to user through the UI
* Single quote for others : strings used as IDs, ...
But maybe it's purely personal.

[onekk]

Usually this is a matter of taste, but there are some exceptions.

If you want to insert quotes in a printed string, you to use "the other quote".

example:

Code: Select all

print("this is a 'sting'")

or

print('this is a "string" ')

The only enforcement in PEP 8 i the use of """ """ in docstrings.

but also if you want to comment out a big portion of code where you have already commented out something with """ """ you have to use ''' '''.

PEP8 however is not affecting the way Python interpreter use the code. As it is easily guessed from reading PEP8 there are some "level" of deprecation.

"definitely not" is usually the most high deprecation level.

PEP8 is somewhat important because if you use a "decent" Python editor usually there is some "checking" about the way code is written, how many blank lines are left between functions, if there are blank line with only spaces, the presence of trailing spaces, and such sort of thing.

Space after operator, and after commas, are important for readability, I often have many indication by my editor (see below), so I'm forced to put them in right places.

I'm using Emacs on Linux not the most modern one, (I've used also VisualStudio (code-oss) and Atom, but I've not found my way, maybe because I have JavaScript) and it is using "flake8"

https://flake8.pycqa.org/en/latest/

that is good way "to remain consistent", but I have put some:

Code: Select all

 # noqa

around my code to stop bothering of something, like "import not used" and similar things.

As usual the right answer is "it depends".

Regards

Carlo D.

[Zolko]

Sadly much of the code I see there is not pep8 compliant.

FreeCAD is mostly coded in C++, and many of the most important libraries that we use are also C++ (OCC, Qt). Therefore, I don't see why we should follow Python coding styles.

A big example is the naming of functions: riceCooker() or RiceCooker() or rice_cooker() . pep8 would mandate rice_cooker() but OCC and Qt already use riceCooker() everywhere, therefore I find it much more elegant and user-friendly to follow a single coding style inside FreeCAD : C++ style riceCooker().

[onekk]

FreeCAD is mostly coded in C++, and many of the most important libraries that we use are also C++ (OCC, Qt). Therefore, I don't see why we should follow Python coding styles.

A big example is the naming of functions: riceCooker() or RiceCooker() or rice_cooker() . pep8 would mandate rice_cooker() but OCC and Qt already use riceCooker() everywhere, therefore I find it much more elegant and user-friendly to follow a single coding style inside FreeCAD : C++ style riceCooker().

Maybe not very precise:

- FreeCAD is written in Python for many parts, obviously for C++ you should use proper C++ writing conventions.

- CamelCase is admitted by PEP8 as is clearly stated that the "preferred way" is to use "Python coding style" i.e the style used in "Python sources", but is told that you could use wathever convention you want, to remain consistent with existing projects.

As a side not I hate Camelcase, because, I always forgot some Capital letter or mistake where his the Capital.
The only advantage is to spare some characters as underscore might make function names slighlty longer. But this is a matter of taste.

Regards

Carlo D.

[chennes]

Speaking for myself, I really only care about consistency here, I don't have a strong feeling about single- versus double quotes. The lines in question actually had both on them, and I think we should pick one. As a fan of the Black code reformatter in my own code I standardize on double quotes in most cases, but as far as I'm concerned, as long as the code uses one or the other I'm happy to merge it.

Here's what Black has to say about it:

Black prefers double quotes (" and """) over single quotes (' and '''). It will replace the latter with the former as long as it does not result in more backslash escapes than before.

[drmacro]

Speaking for myself, I really only care about consistency here, I don't have a strong feeling about single- versus double quotes. The lines in question actually had both on them, and I think we should pick one. As a fan of the Black code reformatter in my own code I standardize on double quotes in most cases, but as far as I'm concerned, as long as the code uses one or the other I'm happy to merge it.

Here's what Black has to say about it:

Black prefers double quotes (" and """) over single quotes (' and '''). It will replace the latter with the former as long as it does not result in more backslash escapes than before.

Not that I have any feelings about it. But, I recently watched a tutorial on strings from Socratica in their Python series.

This thread brings up the use of single or double. But, what of the triple apostrophe or quotation marks?

(and, of course it may totally not pertinent to this thread... )

[Roy_043]

I really only care about consistency here

That level of consistency is probably a pipe dream. In almost all Draft files there is a mix of both single and double quotes, sometimes, as in the example, even on the same line. This is even the case with files that have recently been refactored by a PEP8 advocate (who sometimes took PEP8 a bit too far IMO).