Porting to python3

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
looo
Posts: 706
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Postby looo » Mon Jan 30, 2017 9:06 pm

PR submitted :)

thanks for your efforts. This went straight into master.

Most test are working now. Only two path-specific tests are not working (some import errors). But I think we can fix this directly in master.

So what is next? There are for sure some python3 incompatibilities remaining. But it's quite difficult to find them. Some testing would be nice.
I will try to upload a build of the current state of the python3 branch to anaconda, so everybody on linux can test the branch.
looo
Posts: 706
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Postby looo » Tue Jan 31, 2017 8:02 pm

found a little problem. with python3 this will lead to a endless loop:

Code: Select all

doc = FreeCAD.newDocument()
ellipse = doc.addObject("Part::Ellipse","Ellipse")
ellipse.MajorRadius = 0.5
ellipse.MinorRadius = 0.0


With python2 I get this exception:

Code: Select all

Cannot compute Inventor representation for the shape
wmayer
Site Admin
Posts: 11234
Joined: Thu Feb 19, 2009 10:32 am

Re: Porting to python3

Postby wmayer » Thu Feb 02, 2017 12:40 pm

found a little problem. with python3 this will lead to a endless loop:

Doesn't seem to be Python3 specific. On Windows with Python2 I get the exception in Debug mode, but in Release mode the program freezes.
looo
Posts: 706
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Postby looo » Thu Feb 02, 2017 2:18 pm

strange I get the exception with release + python2 (ubuntu-daily) but freeze with debug + python3.
wmayer
Site Admin
Posts: 11234
Joined: Thu Feb 19, 2009 10:32 am

Re: Porting to python3

Postby wmayer » Thu Feb 02, 2017 2:53 pm

Anyway, an ellipse with a null radius is invalid and should be explicitly handled as error. See git commit 1afa150
looo
Posts: 706
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Postby looo » Fri Feb 03, 2017 10:02 am

Thanks. There are also other bugs with the draft workbench. It's quite difficult to distinguish between python3 problems and problems from current master...

Another problem with python3 is a random order of the tracker-symbols.
looo
Posts: 706
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Postby looo » Fri Feb 03, 2017 10:31 am

The Snapping tool uses dicts. This dicts are somehow ordered with python2 (at least the elements are always at the same position) For python3 the order is random. But changing the dicts to collections.OrderedDicts solves this issue.
https://github.com/looooo/FreeCAD/commi ... 69fe181353
wmayer
Site Admin
Posts: 11234
Joined: Thu Feb 19, 2009 10:32 am

Re: Porting to python3

Postby wmayer » Fri Feb 03, 2017 12:47 pm

The Snapping tool uses dicts. This dicts are somehow ordered with python2 (at least the elements are always at the same position) For python3 the order is random. But changing the dicts to collections.OrderedDicts solves this issue.

Does this cause any problems? My experience with Python dicts is that the order is undefined which was surprising me at the beginning because the counterpart in C++ is a map and there it's always sorted by the key.
looo
Posts: 706
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Postby looo » Fri Feb 03, 2017 1:12 pm

http://stackoverflow.com/questions/1495 ... in-python3
Python has never guaranteed iteration order of keys in a dict or set

HASH RANDOMIZATION IS DISABLED BY DEFAULT.
which was changed for python 3.3 regarding this link.

So we shouldn't rely on the ordered dicts in python2. As it's not good to randomly order the draft-tracker/snap-symbols (python3) I think it's best to use the collections.OrderedDicts. https://docs.python.org/2/library/colle ... rderedDict
User avatar
yorik
Site Admin
Posts: 8563
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Porting to python3

Postby yorik » Sat Feb 04, 2017 3:36 pm

wmayer wrote:Does this cause any problems? My experience with Python dicts is that the order is undefined

Yes that's what I believed too... Certainly in Draft I never relied on the order of dict elements I think.