Discussion: using FreeCAD or App namespaces, which is prefered

[vocx]

good question. In FEM nearly 100 % of the code uses FreeCAD or FreeCADGui. Why? Just because I did not know about the App and FreeCAD ...

Exactly my point. There is no standard. People start coding looking at the code that was there previously.

In my opinion, it looks neater to write App and Gui, because you separate the namespaces clearly; one doesn't need the GUI at all (vectors, basic properties, etc.), and the other really requires the GUI (selection, active view, etc.).

But maybe there is some reason to use one or the other? I don't know. Maybe it was just a way for Jürgen to save typing code, and there is no other reason?

[triplus]

It does. It is defined in FreeCADInit.py, and in fact it is simply:

Code: Select all

# some often used shortcuts (for lazy people like me  ;-)
App = FreeCAD
Log = FreeCAD.Console.PrintLog
Msg = FreeCAD.Console.PrintMessage
Err = FreeCAD.Console.PrintError
Wrn = FreeCAD.Console.PrintWarning

Mystery resolved! As we are talking about sensible (documentation) guidelines:

Code: Select all

import FreeCAD as App
import FreeCADGui as Gui

And after use such aliases in the code. Not adding such import statements, that could in my opinion lower the reliability of the code is some situations. In addition it would introduce ambiguity. People wondering, where did the Gui and App came from?

P.S. Qt 6 devs plan to explore and introduce "more Pythonic" API and FreeCAD currently supports Python modules with two different import styles. Therefore guidelines could change in the future.

[ezzieyguywuf]

It does. It is defined in FreeCADInit.py, and in fact it is simply:

Code: Select all

# some often used shortcuts (for lazy people like me  ;-)
App = FreeCAD
Log = FreeCAD.Console.PrintLog
Msg = FreeCAD.Console.PrintMessage
Err = FreeCAD.Console.PrintError
Wrn = FreeCAD.Console.PrintWarning

Mystery resolved! As we are talking about sensible (documentation) guidelines:

Code: Select all

import FreeCAD as App
import FreeCADGui as Gui

And after use such aliases in the code. Not adding such import statements, that could in my opinion lower the reliability of the code is some situations. In addition it would introduce ambiguity. People wondering, where did the Gui and App came from?

P.S. Qt 6 devs plan to explore and introduce "more Pythonic" API and FreeCAD currently supports Python modules with two different import styles. Therefore guidelines could change in the future.

I started looking at how to add this, at least for App and Gui.

Once I have something together I cna post it in here for review, and we can discuss if we should make the change across the board for other aliases as well.

[triplus]

I started looking at how to add this, at least for App and Gui.

Before doing that, best to first resolve the question, on what is the problem we are trying to resolve. As i read this discussion more as an question, on why some use:

Code: Select all

import FreeCAD

Or:

Code: Select all

import FreeCAD as App

And what should the documentation recommend by default. Why using App just works in some use cases and things like that. I feel that most of that got answered already. As for the rest, i don't even know what is the goal anymore, or what you propose to work on. But sure, go ahead and keep us posted.

[ezzieyguywuf]

Before doing that

whoops. I guess you were too slow (or I was too fast...)

Really, though, this merely shows an example of how this can be accomplished.

2019-09-06 17_13_50-Clipboard.png (37.47 KiB) Viewed 1102 times

I don't understand these "# <string>(36)" artifacts, as I'm using doCommand in exactly the same way as the Arch workbench. Of course, I've never used the Arch workbench so for all I know these artifacts exist there too...

That being said, one big problem with this approach is that it only shows the import statement in the Gui. What about when the user is running from command mode?

Really: shouldn't doCommand operate independent of whether the Gui is active or not? That would be more of a change/update.

Actually, I've also been toying with the idea of updating the cli interface to provide simple things such as tab-completion, history, etc... using something like gnu readline.

Anywho, to address your question:

best to first resolve the question, on what is the problem we are trying to resolve

I don't know that there is a problem, other than inconsistency and poorly documented practices.

In general, python allows users the freedom to do what they want with importing modules and using aliases. In general, most numpy documentation will utilize the "np" alias, but they make this extremely clear in every bit of sample code that they provide. They always show the "import numpy as np" line (I think, don't quote me on that...)

That being said, I think we simply need to do the same. Users are still free to use the full module name (I tend to have a preference for avoiding aliases, except for well-known ones like np and pd). We just need to make it clear to our users what we're doing in the example code that we publish and generate.

[triplus]

Always nice to see examples in code. Now on how much sense does such change make. ATM i don't know. In my opinion developers should always import modules they use manually. Otherwise we would introduce some practice, not all that common in Python world.

Actually, I've also been toying with the idea of updating the cli interface to provide simple things such as tab-completion, history, etc... using something like gnu readline.

Sounds good. Now this would i guess be optional? Due to being GPL licensed and due to policy FreeCAD has on licenses. Anyway, there have been numerous attempts to improve Python console in the past. Not much results, though. In addition i am not sure on how advanced is the usage of Python console ATM. As for basic things, it does the job.

[ezzieyguywuf]

Due to being GPL licensed and due to policy FreeCAD has on licenses.

Well, I guess we could use the python cmd module instead if the license will be an issue. This may be a bit trickier as the python console is written entirely in C, but it should be possible.

Anyway, there have been numerous attempts to improve Python console in the past. Not much results, though.

I'd be interested in reading about some of these attempts if you have any links.

In addition i am not sure on how advanced is the usage of Python console ATM. As for basic things, it does the job.

I'll do development remotely at times, and it's usually a pain to run simple tests using a gui (I have to log in to VNC etc...) In these cases, I prefer to use the cli, however it's so painful that I usually just write a quick script and run that instead.

[triplus]

Good question. I remember some discussions, and some prototypes too, around build-in text editor, debugging support and things like that. But no links emerge if i do a quick search.

[vocx]

Before doing that, best to first resolve the question, on what is the problem we are trying to resolve. As i read this discussion more as an question, on why some use:...

And what should the documentation recommend by default. ...

Correct. Today there is no real "problem", it's only a question of consistency. A lot of the programming documentation uses App, while seemingly many other places use FreeCAD. It's an inconsistent style. The software itself outputs "App-style commands", so I think we should prefer this style because it agrees with what the user will see from the Python console.

[ezzieyguywuf]

So, in the code sample I made, I explicitly delete FreeCAD and FreeCADGui from the namespace. The reason for this is that I did not explicitly display to the user the import of FreeCAD and FreeCADGUI - rather, I showed them "import FreeCAD as App" and "import FreeCADGui as Gui".

However, when running the unit tests on this code, some of them fail because they expect for "someone else" to have imported the name FreeCAD already.

So, this is sort of at the core of the question that is being asked here - is that assumption a good one? Or is this particular test poorly written, and needs to import FreeCAD itself?

It does seem redundant to me to have both FreeCAD and App in the same namespace.