[Python-Dev] Global interpreter lock/import mechanism
Guido van Rossum
guido@python.org
Thu, 30 Jan 2003 12:51:45 -0500
> 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/)