Porting to python3

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Post by looo »

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.
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Post by looo »

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
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Porting to python3

Post by wmayer »

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.
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Post by looo »

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

Re: Porting to python3

Post by wmayer »

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

Re: Porting to python3

Post by looo »

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.
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Post by looo »

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
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Porting to python3

Post by wmayer »

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.
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: Porting to python3

Post by looo »

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
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Porting to python3

Post by yorik »

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.
Post Reply