Python coding standard

About the development of the FEM module/workbench.
User avatar
bernd
Posts: 3869
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Python coding standard [WORK IN PROGRESS]

Postby bernd » Thu Nov 05, 2015 8:57 am

PrzemoF wrote:Internal modules that are not supposed to be used in scripting. It doesn't look nice and I'm not convinced that it's right, but that's the meaning. Probably we are not very consistent with that naming.
Thanks. My first impression is, I really like it. I'm gone open a new thread in this regard as soon as I have finished splitting of FemShellThickness.

related: viewtopic.php?f=18&t=12883&start=30#p104961
User avatar
PrzemoF
Posts: 1706
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Postby PrzemoF » Thu Nov 05, 2015 9:17 am

OK, I added it to the opening post.

Is that type of licence header acceptable [1]?

Code: Select all

#*   Copyright (c) 2015 - FreeCAD Developers                               *
#*   Author: Przemo Firszt <przemo@firszt.eu>                              *

or it should always point to Jürgen as the copyright holder?

[1] https://github.com/FreeCAD/FreeCAD/blob ... ader.py#L2
User avatar
yorik
Site Admin
Posts: 8553
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Postby yorik » Thu Nov 05, 2015 1:19 pm

PrzemoF wrote:or it should always point to Jürgen as the copyright holder?

No, you own the copyright on the files you created. Ideally each person who contributes code to a file should be added, but in practice nobody does that...

I'm not sure that your version works everywhere (the owner of the copyright is the FreeCAD developers). For ex. debian is very picky about copyright, they often whine when these things are not 100% correct. I don't know if they accept the copyright in that form... This should be checked first
User avatar
PrzemoF
Posts: 1706
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Postby PrzemoF » Thu Nov 05, 2015 1:40 pm

This is a very thin legal ice as the problems might show up 10 years down the line (*). I think one of the reasons why linux kernel is not using GPLv3 is that this change would require to get permission of all previous developers which is almost impossible. Keeping licence in one file that covers all files (might not be possible) is much easier to control. Anyway, I'm OK with whatever is agreed by the core devs.

(*) ... when FreeCAD rules the CAD world and some of the developers are retired on some exotic islands without internet access to contact them ;)
User avatar
bernd
Posts: 3869
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Python coding standard [WORK IN PROGRESS]

Postby bernd » Wed Nov 11, 2015 9:27 am

I would vote for the following in FEM:

- all new created code files should have unix line endings
User avatar
PrzemoF
Posts: 1706
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Postby PrzemoF » Wed Nov 11, 2015 9:49 am

I don't mind forcing LF as line end, but I think that there is a silver bullet solution. We need to ask the core devs for help. Some reading [1] from the first answer:
"However, there's a better alternative: Benefit from LF line endings in your Linux workdir, CRLF line endings in your Windows workdir AND LF line endings in your repository.

As you're partially working on Linux and Windows, make sure core.eol is set to native and core.autocrlf is set to true.

Then, replace the content of your .gitattributes file with the following

* text=auto

This will let Git handle the automagic line endings conversion for you, on commits and checkouts. Binary files won't be altered, files detected as being text files will see the line endings converted on the fly."

I'll be testing it in on my repo:

Code: Select all

[przemo@localhost freecad]$ git config --global core.eol true
[przemo@localhost freecad]$ git config --global core.eol native
and "* text=auto" in .gitattributes

[1] http://stackoverflow.com/questions/9976 ... rking-copy
User avatar
bernd
Posts: 3869
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Python coding standard [WORK IN PROGRESS]

Postby bernd » Wed Nov 11, 2015 10:50 am

PrzemoF wrote:I don't mind forcing LF as line end, but I think that there is a silver bullet solution. We need to ask the core devs for help. Some reading [1] from the first answer:
"However, there's a better alternative: Benefit from LF line endings in your Linux workdir, CRLF line endings in your Windows workdir AND LF line endings in your repository.

As you're partially working on Linux and Windows, make sure core.eol is set to native and core.autocrlf is set to true.

Then, replace the content of your .gitattributes file with the following

* text=auto

This will let Git handle the automagic line endings conversion for you, on commits and checkouts. Binary files won't be altered, files detected as being text files will see the line endings converted on the fly."

I'll be testing it in on my repo:

Code: Select all

[przemo@localhost freecad]$ git config --global core.eol true
[przemo@localhost freecad]$ git config --global core.eol native
and "* text=auto" in .gitattributes

[1] http://stackoverflow.com/questions/9976 ... rking-copy


I'm fine with the line endings. If a file has mixed line endings I know how to handle this with git (viewtopic.php?t=11952#p96124). You'll be fine anyway since vi is the only editor I know of who really can handle files with mixed line endings. Big problem with all these autocrlf is, one has to know how to use it. Lots off people do not know. Means we will get into trouble again and again ... There are lots of commits in FreeCAD master changing only a few lines off code in a file but changing line endings off this file too.
User avatar
PrzemoF
Posts: 1706
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Python coding standard [WORK IN PROGRESS]

Postby PrzemoF » Wed Nov 11, 2015 10:59 am

OK, so " eol=lf" probably is the way to go
"Set to string value "lf"
This setting forces Git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out."

I'm OK (linux + vim, always) with that, but I don't know how it would affect win developers.

[1] https://www.kernel.org/pub/software/scm ... butes.html
User avatar
bernd
Posts: 3869
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Python coding standard [WORK IN PROGRESS]

Postby bernd » Wed Nov 11, 2015 11:14 am

PrzemoF wrote:OK, so " eol=lf" probably is the way to go
"Set to string value "lf"
This setting forces Git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out."

I'm OK (linux + vim, always) with that, but I don't know how it would affect win developers.

[1] https://www.kernel.org/pub/software/scm ... butes.html


Problems could happen from Linux to Linux too. Assumed a file has windwos line endings. You add two lines to it. These two lines will have unix line endings because vi can handle mixed line endings. If this file is edited by any editor which can not handle mixed line endings it will save the file using one line ending for all lines. If one does not know git properly the line endings will land in FreeCAD master ...
User avatar
Kunda1
Posts: 621
Joined: Thu Jan 05, 2017 9:03 pm

Re: Python coding standard

Postby Kunda1 » Tue Feb 07, 2017 1:15 pm

I listed FEM files that could use a peak at their documentation (list created from a regex) to meet the standards mentioned in the thread.

https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28
https://github.com/FreeCAD/FreeCAD/blob ... py#L23-L28