Feature proposal: user defined (Python?) functions for Expressions and Spreadsheets

[wolfgangr]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

From elaborated office spreadsheets (and other applications), we know that we can supply user defined functions to expand the functionality of the formula language in customized manner.

In the FreeCAD envrionment, I'd assume that Python were the language of choice for such an endeavour.

In @realthunder 's Wiki
https://github.com/realthunder/FreeCAD_assembly3/wiki/Expression-and-Spreadsheet
there even is described an elaborated ability to acces python in Expressions (and thus in spreadsheets, too).

However, I failed to reproduce this on current stable 0.21.2.

• Was this feature merged already?
• Did I just miss the proper documentation how to use it?
• Is there some hidden way to switch this on?
• Is this feature available in current dev?
• Are there any plans in the future to add it?
• Is there any other way to extend the expression engine at user level?

On my journey from bloody novice to still-bloody silly-user in FreeCAD, there were two occasions where I really missed user defined functions:

• "Law of cosine" to calculate the angles in a triangle, provided three lengths, to nail down flipping sketches
  https://forum.freecad.org/viewtopic.php?t=86102
• Access to global placement of linked items, which is broken in the "globalPlacement" as accessible by Expressions/Spreadsheets, but available by workaround in Python
  https://forum.freecad.org/viewtopic.php?p=759225#p759225

Of course, this are mere examples, other people may have other needs in mind.

From my experience, user defined functions (e.g. in Excel) reduce the amount of programming and object integration required to a considerable extent, compared to implement a far wider superset of the functionality in high level language, as it seems the way to go with FreeCAD at the moment - see e.g.
https://wiki.freecad.org/Python_scripting_tutorial

Full version info

[code]
OS: Debian GNU/Linux 10 (buster) (LXDE/LXDE)
Word size of FreeCAD: 64-bit
Version: 0.21.2.33771 (Git)
Build type: Release
Branch: (HEAD detached at 0.21.2)
Hash: b9bfa5c5507506e4515816414cd27f4851d00489
Python 3.10.13, Qt 5.15.8, Coin 4.0.0, Vtk 9.2.6, OCC 7.6.3
Locale: German/Germany (de_DE)
Installed mods: 
  * fasteners 0.5.17
  * slic3r-tools
  * Pyramids-and-Polyhedrons
  * A2plus 0.4.64
  * Assembly3 0.12.2
  * Assembly4 0.50.12
  * FeedsAndSpeeds 0.5.0
  * dodo 1.0.1
  * frame 0.1.1
  * freecad.gears 1.2.0
  * Manipulator 1.5.7
  * MOOC 2022.4.21
  * Help 1.0.3
  * ose-piping
  * QuickMeasure 2022.10.28
  * sheetmetal 0.4.11
  * ThreadProfile 1.89.0
  * SteelColumn
  * Estimate 0.1.2
  * DynamicData 2.60.0
  * parts_library
  * btl 0.9.9
  * AnimationFreeCAD 1.0.0 (Disabled)
  * CurvedShapes 1.0.8
[/code]

Subproject(s) affected?

Expressions

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[krushia]

• Feature hasn't been merged yet. TNP fixes are happening first.
• You didn't miss any documentation.
• No hidden switch.
• Not in dev either.
• Go here: App/Gui: Refactor expression completer and unit expressions #3062
• Expressions can't be extended without coding and recompiling, no. Expressions aren't at the Python level.

It only works in realthunder's Link branch for now unfortunately.

I've taken notice of your forum threads while on my own FreeCAD learning journey. We seem to have similar frustrations regarding limitations of expressions and general disconnect between the GUI and the object-oriented base it rests on.

IMHO FreeCAD really needs a safe scripting system (like Lua?) that allows us to do some level of programming that gets saved in the FCStd file. That or a way to put Python macros in it and ask the user if its okay to run them. Anyway, you are not alone.

[Zolko-123]

Embedding Python code into a FCStd file has been discussed many times and is refused for security reasons : to separate data and code. If you want to ship your own code there are already many available methods (macro, FC object ...)

[pitch-circle]

there were two occasions where I really missed user defined functions:

Having two occasions where something different would help you is quite a long way from justifying opening up Expressions to full-on Python. To me, the proposed solution is overkill for the problems. Also, the two issues you identify are quite different in scope.

Cosine rule can already be done with Expressions, it just needs a little more typing.

The global placement issue is different and might be fixed locally by opening up just that part which is currently closed to Expressions.

What I am saying is that until the RT changes reach the top of the in tray, small wins in focussed or targeted places might be easier to achieve.

On cosine rule, please see https://github.com/sbyrnes321/trianglesolver A similar solve() function might be easier to add to the list of permitted Expressions (cube root was added recently as a standalone function, even though exponentiation to 1/3 has long been possible).

[wolfgangr]

It's not about begging for a fish (or two), but about empowering users to do fishing on their own, in general.

Regarding choice of language, I think, any Turing complete language might do. May be even some superset of the current expression language, complemented by some control structure and skd of "define function"?

My favour for Python was due to the native access to object properties - which leads to the question of security.
Might it ease the concerns to limit access to read-only, and may be only to objects visible in the tree of the current file?
I have no clue about the architectural nuts&bolts of Python. Whether it were possible to limit part of it in a "sandbox" like way. Maybe it would require an independent instance of python (which we would need for e.g Lua anyway).

I understand that the development carawane has priority towards TNP.
It's FOSS, anyway, and in the end, every feature has to be honoured as a gift, of course.

But coming new from outside, I see the FreeCAD communty falling into two parties regarding TNP:

• avoid it
• attack it

Why do associations of primordial reptile instincts come to my mind? Humans have learned to overcome such instincts with rational decisions. But they are still humans, prone to be caught by emotional patterns, I know....

E.g. there is a sketching wiki (I consider flipping sketches the little sister of TNP, OK?), suggesting to avoid datum constraints as fas as possible. And there is a TNP wiki, suggesting the opposite: relying on datum constraints as far as possible, to keep control on the model.

From a sportive or hunting spirit, I'm with the TNP attackers: Failure is not an option. We'll do it, because we can do it. And FreeCAD is going to be THE one FOSS CAD, so there is no room for compromise. OK.

I also see that toddler like attachment aka "wanna this, there, that way..." appears fast, efficient and attractive, in the first moment. But many time I have allowed myself to be lured down that way, I had to pay long hours of repairing my designs, as soon as I wantet to apply some minor modifications.

There are people who just want to do some mediocre designs. Like me, but not only. Have their sportive goals in other areas. Instead of elaborate ways to cope with inevitable ambiguities resulting from the behaviour of sophisticated solvers, they tend to avoid those solvers all togehter, as long as they don't se a real advantage for their specific design.

People like me, who start to keep track of all placement of assembled subelements in a spreadsheet now, since, as soon as I loose control, I have hard times to gain it back. Cumbersome, but safe. And in the end much faster than reparing a complex model that has fallen apart due to uncomprehensible opaque automagics.

I understand that at the moment, there is no way to implement my idea. Can live with that.
But why not just keep this issue as a collector of ideas and whishes?

So, I'd suggest that some authorized developer might rate this issue as "delayed but not forgotten forever"?
Thank You :-)

[adrianinsaval]

python in expressions would be a security nightmare so I don't think we'll do that. User defined functions could be a desirable feature