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.)
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 ? ).
No, replacing __import__ is the designated API for this.
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 ?
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/)