Global interpreter lock/import mechanism
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:
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). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach
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).
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.)
No, replacing __import__ is the designated API for this.
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:
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.
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 -- Greg Ward <gward@python.net> http://www.gerg.ca/ I had a ploughman's lunch the other day. He wasn't very happy.
On Thu, Jan 30, 2003, Joerg Budischewski wrote:
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). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach
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).
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.)
No, replacing __import__ is the designated API for this.
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:
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.
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 -- Greg Ward <gward@python.net> http://www.gerg.ca/ I had a ploughman's lunch the other day. He wasn't very happy.
participants (4)
-
Aahz -
Greg Ward -
Guido van Rossum -
Joerg Budischewski