Issue 58103 - python : adding import facility and basic-like functions
Summary: python : adding import facility and basic-like functions
Status: UNCONFIRMED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: OOo 2.0
Hardware: All Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-18 12:20 UTC by bmarcelly
Modified: 2013-07-30 02:47 UTC (History)
3 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Proposal to enhance python scripting, version 1.0 (25.24 KB, application/x-compressed)
2005-11-18 12:22 UTC, bmarcelly
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description bmarcelly 2005-11-18 12:20:38 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.
Comment 1 bmarcelly 2005-11-18 12:22:18 UTC
Created attachment 31607 [details]
Proposal to enhance python scripting, version 1.0
Comment 2 kay.ramme 2005-11-22 09:22:57 UTC
Joerg, please take this over ... :-)
Comment 3 joergbudi 2005-12-06 20:42:35 UTC
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
Comment 4 bmarcelly 2005-12-09 14:24:23 UTC
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
Comment 5 bmarcelly 2005-12-09 14:38:22 UTC
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.
Comment 6 Stephan Bergmann 2007-04-11 15:03:09 UTC
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]
Comment 7 Stephan Bergmann 2007-06-27 16:45:56 UTC
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]
Comment 8 Stephan Bergmann 2008-02-12 14:15:28 UTC
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]
Comment 9 Rob Weir 2013-03-11 15:02:29 UTC
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
Comment 10 Rob Weir 2013-07-30 02:47:02 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.