To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=58103
------- Additional comments from [EMAIL PROTECTED] Tue Dec 6 12:42:35 -0800 2005 ------- 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 --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
