triplus wrote: ↑Fri Sep 06, 2019 5:24 pm
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 1096 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:
triplus wrote: ↑Fri Sep 06, 2019 5:24 pm
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.