Migration
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Migration
Fairly speaking I'm not really exited about that.
On one hand the migration itself shouldn't exceed a couple of hundred of lines and mostly it needs just final polish (and some algorithmic decisions)... On the other hand I suppose the PartDesign's python bindings may be not completely implemented and/or particularly broken because it isn't heavily used now, so It will likely need to be fixed too...
So, All in all I don't really see any other benifites in it but "Python is cool" ...
Note that I'm not really familiar with python part of the freecad code, so I may be wrong...
On one hand the migration itself shouldn't exceed a couple of hundred of lines and mostly it needs just final polish (and some algorithmic decisions)... On the other hand I suppose the PartDesign's python bindings may be not completely implemented and/or particularly broken because it isn't heavily used now, so It will likely need to be fixed too...
So, All in all I don't really see any other benifites in it but "Python is cool" ...
Note that I'm not really familiar with python part of the freecad code, so I may be wrong...
-
DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Migration
To me, it feels like migration is not much more than just exploring properties of objects, creating some new objects, modifying properties of existing objects. This is doable with Python out of the box.
The benefits are great.
* if something unexpected happens, C++ code has an awful habit of crashing. In Py, you generally just get an error.
* algorithm can be tweaked without having to rebuild FreeCAD. And even a user (an advanced user, of course) can tweak it to accommodate his very special project. For me, it is a very big deal, because build time of FreeCAD is 8-10 minutes at best (can be an hour, if multiple stupid compile errors pop up).
* py code is less coding. For example, there is no need to write long and error prone type casting.
* migration seems to be already just a train of Py commands, inconveniently coded via doCommand("Py line of code")
It can even be a separate macro.. Or a set of separate macros!
The benefits are great.
* if something unexpected happens, C++ code has an awful habit of crashing. In Py, you generally just get an error.
* algorithm can be tweaked without having to rebuild FreeCAD. And even a user (an advanced user, of course) can tweak it to accommodate his very special project. For me, it is a very big deal, because build time of FreeCAD is 8-10 minutes at best (can be an hour, if multiple stupid compile errors pop up).
* py code is less coding. For example, there is no need to write long and error prone type casting.
* migration seems to be already just a train of Py commands, inconveniently coded via doCommand("Py line of code")
It can even be a separate macro.. Or a set of separate macros!
Re: Migration
yes, but It's likely uses some functions not exported in python (I suppose so, I haven't looked precisely)...DeepSOIC wrote:To me, it feels like migration is not much more than just exploring properties of objects, creating some new objects, modifying properties of existing objects. This is doable with Python out of the box.
sure, I call it «python is cool» =)DeepSOIC wrote:The benefits are great.
As well as every other command... that's done intentional so they correctly work with macros. I'm not sure how this should be done in python, but I suppose in the same way...DeepSOIC wrote:* migration seems to be already just a train of Py commands, inconveniently coded via doCommand("Py line of code")
I agree that Gui code for most of modules is easier and more reliable to write in python, but I don't see reasons to rewrite already made code, just because of that...
If you want you may take a shot, but I won't like to merge it unless it will be in all ways not worser when it currently is.
Also if you just want to do some python work, you may check and fix up InvoluteGear and ShaftWizard. I've heard there were something wrong with them...