Hi,
I am one of the authors of the python binding for the OpenOffice' component model UNO( see http://www.openoffice.org and http://www.budischewski.com/pyuno/python-bridge.html).
First of all, let me say, that is real fun to work with python C API and its documentation.
However, there are still some open questions, for which I haven't found an answer in the documentation.
1) I can't find an API call to get to know, whether the current thread has the global interpreter lock or not. ( A recursive lock would also help).
Some background: UNO objects are also reference counted, when they get destructed, they may need to PY_DECREF python references. However, the OpenOffice object's dtor might either be called with or without global interpreter lock.
I currently workaround this by delegating the PY_DECREF to a new thread, however, which has the defined state (it does not have the lock, so it must acquire it), but this is quite inefficient.
2) I would like to hook into the python import mechanism in order to introduce new classes. I currently do this by replacing the __builtin__.__dict__["__import__"] with my own version, which delegates to the original function and in case of failure tries to lookup a UNO type.
This allows e.g. by writing
from com.sun.star.uno import XComponent
to elegantly create such UNO types.
However, I think, the replace-__import__-function is quite a nasty solution, I would rather like to have an API for this. Is there an API I have overlooked (or is it planned to have something like that ? ).
3) The Python-UNO bridge can be used within the python process or within the office process itself ( so called UNO components). For the latter, the binding initializes python by calling Py_Initialize().
As you might know, OpenOffice.org comes as a binary (not in source) even on unix platforms. But I don't want to decide at buildtime, which Python version the user should use (and actually I don't want to ship python), instead I want to reuse a python version, which already exists on the system.
But currently, the python unix buildprocess does not create a shared library, only a static lib (while on windows a shared library gets built).
Are there any plans to add also a shared libs for unix ?
Thx in advance,
Joerg
On Thu, Jan 30, 2003, Joerg Budischewski wrote:
I am one of the authors of the python binding for the OpenOffice' component model UNO( see http://www.openoffice.org and http://www.budischewski.com/pyuno/python-bridge.html).
Welcome! This list is for core Python development, not for people using Python. Although it's much higher traffic, please use comp.lang.python (also available as python-list).
- I can't find an API call to get to know, whether the current thread
has the global interpreter lock or not. ( A recursive lock would also help).
Sorry, this is not supported. (It's a contentious issue -- search the archives for more info, I don't have the time to shed more light on it.)
- I would like to hook into the python import mechanism in order to
introduce new classes. I currently do this by replacing the __builtin__.__dict__["__import__"] with my own version, which delegates to the original function and in case of failure tries to lookup a UNO type.
This allows e.g. by writing
from com.sun.star.uno import XComponent
to elegantly create such UNO types.
However, I think, the replace-__import__-function is quite a nasty solution, I would rather like to have an API for this. Is there an API I have overlooked (or is it planned to have something like that ? ).
No, replacing __import__ is the designated API for this.
- The Python-UNO bridge can be used within the python process or within
the office process itself ( so called UNO components). For the latter, the binding initializes python by calling Py_Initialize().
As you might know, OpenOffice.org comes as a binary (not in source) even on unix platforms. But I don't want to decide at buildtime, which Python version the user should use (and actually I don't want to ship python), instead I want to reuse a python version, which already exists on the system.
But currently, the python unix buildprocess does not create a shared library, only a static lib (while on windows a shared library gets built).
Are there any plans to add also a shared libs for unix ?
Python 2.3 does this for Linux.
But I think you would be better off shipping your own Python -- depending on whatever Python version happens to be installed is very brittle, especially if (as you are) you're using the extension C API.
--Guido van Rossum (home page: http://www.python.org/~guido/)
On 30 January 2003, Joerg Budischewski said:
- I would like to hook into the python import mechanism in order to
introduce new classes. I currently do this by replacing the __builtin__.__dict__["__import__"] with my own version, which delegates to the original function and in case of failure tries to lookup a UNO type.
[...]
However, I think, the replace-__import__-function is quite a nasty solution, I would rather like to have an API for this. Is there an API I have overlooked (or is it planned to have something like that ? ).
This has got to be one of the all-time most-discussed topics on python-dev. Check the archive for last November/December for an enormous discussion.
But currently, the python unix buildprocess does not create a shared library, only a static lib (while on windows a shared library gets built).
Are there any plans to add also a shared libs for unix ?
Take a look at the Debian package for Python. I don't know exactly how they do it, but I have /usr/lib/libpython{1.5,2.1,2.2}.so on my system. Nice.
Greg
-
Aahz -
Greg Ward -
Guido van Rossum -
Joerg Budischewski