Apache OpenOffice (AOO) Bugzilla – Issue 58103
python : adding import facility and basic-like functions
Last modified: 2021-05-30 09:35:08 UTC
This is a proposal to enhance python scripting capabilities in OpenOffice.org 2.0. It has been tested in version 1.9.130, with a patch to module uno.py. A python script writer will get these improvements: - capability to import modules from folders or sub-folders of /share/Scripts/python and /user/Scripts/python - API handling greatly simplified by functions inspired from Basic - same user interaction as with Basic MsgBox and InputBox - facility to call a dialog created with the Dialog Editor of OpenOffice - easy conversion to python of existing Basic scripts - introspection of API objects and variables by a simple call to Basic Xray Next attachment is a zip file containing a full description of the proposal, a python module containing the helpers, a Basic module, and example files.
Created attachment 31607 [details] Proposal to enhance python scripting, version 1.0
Joerg, please take this over ... :-)
Hi, I looked through your suggestions last weekend. - I espescially welcome your helper functions for calling scripts, creating properties, etc. I have another contribution, which adds the bootstrap() function available in java or c++. For this, I plan to create an officehelper.py, which will be in the office/program directory. That's from my point of view the place, where your helper functions should be added to. See http://www.openoffice.org/issues/show_bug.cgi?id=54532 I have suggestions for renaming some functions, but this should be later discussed in detail. Beside this, you should also implement regression tests for the functions. This will pay off, when one later needs to fix a bug in the functions and one need to ensure, that the scripts still do the right thing. - I have problems with your suggestion for supporting the import-feature. * It is not thread safe (two concurrent scripts might modify sys.path inconsistently, so that one of them won't run anymore). * imports can only be done once while the office is running. This in general effects only the script developer but is a caveeat nevertheless * Scripts from different vendors might affect each other inconsistently. * Later imports don't work (you can have an import within a function or a class, it is executed, when the functions gets called, but at this time, the sys.path is resetted again. I can think of two other solutions: 1) The scripting framework adds a property (e.g. __unoimport__ ) to each script module, which exports a function import(). One can then do __unoimport__.import( "modulename" ) __unoimport__.import( "modulename", (list-of-symbols-to-import) ) __unoimport__.import( "modulename", {hashmap-of-symbols-to-import-plus-their-local-names) ) positive: The imported module is not added to the global module list. positive: The imported modules have the same lifetime as the script module. positive: One can import selfwritten scripts positive: thread safde negative: Self made import syntax, not very python like negative: One can't distribute arbitrary third party python libraries, because they will try to use standard python import mechanism. 2) Use a new python interpreter for every imported script. Thus every Script has its own python environment including the global module list. positive: standard import mechanism works positive: Different 3rd party components can't interfere. negative: needs to be implemented in the native part of pyuno (you can't create other interpreters from python) negative: Performance problems (one interpreter per script negative: not yet sure, whether this is implementable. What's your opinion on these comments ? Bye, Joerg
Hi Joerg, "I plan to create an officehelper.py, which will be in the office/program directory. That's from my point of view the place, where your helper functions should be added to." Of course, that was my first implementation. But I think it's not a good idea to put here python functions which are not essential to the system. Note that uno.py already contains such functions! Anyone can create other useful functions, and the logical place is in a sub-directory of /share/Scripts/python Problems with import feature I am not surprised of these drawbacks because I work on a single user system. However if a helper file placed in office/program would not provide identical problems, then it should be the same for a helper file placed in a sub-directory of /share/Scripts/ python. My method may not be a good solution, but the system should be able to look into these subdirectories. Even an import limited to a subdirectory of /share/Scripts/python would be a good feature for deployment of common routines. Your solution number 2 is more clean, but I can't help you more on this. I suspect there may be other memory problems with current python implementation. It seems that each executed script keeps some of its data : variables declared at a module level are still accessible on another run of the same script; it could be the same for other module-related data. So there is a sort of memory leak if OpenOffice is never stopped and many scripts run. I fear that, with multiple threads, the leak becomes a problem. Regression tests : I never did this. Please give me pointers to more information (how to do this). If it can be done without C++ knowledge, I can try. Regards, Bernard
Correction of my previous comment. Read: Problems with import feature I am not surprised of these drawbacks because I work on a single user system. My method may not be a good solution, but the system should be able to look into /share/Scripts/ python subdirectories. Even an import limited to a subdirectory of /share/Scripts/python would be a good feature for deployment of common routines.
To prevent frustration among patch writers, all issues of type PATCH are monitored for extended inactivity periods, see <http://eis.services.openoffice.org/patchreport/irt_index.html> and <http://eis.services.openoffice.org/patchreport/iit_index.html>. Please proceed with this issue in an appropriate way, to satisfy the statistics and avoid frustration. Thanks. [http://wiki.services.openoffice.org/wiki/Uno/Misc/InactivePatchIssueReminder]
I'm adding this comment to all open issues with Issue Type == PATCH. We have 220 such issues, many of them quite old. I apologize for that. We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0. If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know. On the other hand, if the patch is no longer relevant, please let us know that as well. If you have any general questions or want to discuss this further, please send a note to our dev mailing list: dev@openoffice.apache.org Thanks! -Rob
Reset assignee on issues not touched by assignee in more than 1000 days.
This patch does not fix anything, but improve python scripting. The collection is under LGPL 2.1. We should look at this one when we look at the way scripting is done in general. But I am not sure if the collection has any direct Value to us today. I suggest to move the Collection to a different resource. Maybe Wiki sounds like a fair idea and close the Report here. suggestions?