Why not standard ? (Re: Building a shared libpython)

[Paul Duffin]

Paul Duffin wrote:
> 
> Fredrik Lundh wrote:
> >
> > Carlos A M dos Santos <nospamplease at inf.ufrgs.br> wrote:
> > > I'm installing Python 1.5.2 and noted that there is no configure option to
> > > buld a shared libpython.  How could I do it?
> >
> > www.python.org => search => newsgroup search for
> > "shared libpython" brings up lots of hits.  start with
> > these:
> >
> >     http://www.deja.com/=dnc/getdoc.xp?AN=488431463
> >     http://www.deja.com/=dnc/getdoc.xp?AN=398994871
> >
> 
> Why is this not available with the standard distribution ?
> Could someone who knows explain why, or someone who can add it to the
> standard distribution.
> 

Fredrik kindly pointed me at 
	http://www.deja.com/=dnc/getdoc.xp?AN=398994871
again, (I did not look at it because I assumed it was a "how to").
In it Guido gives his reasons for why he considers a shared library
version of Python a low priority.

GvR writes:
> It's just a nightmare to get this to work on all different platforms.
> Shared library portability is a pain.

I do not think that it is as hard as all that; Python already supports 
loadable extensions (which I presume are shared objects) so all that
is left is dynamic linking / binding, and shared library issues.

On Unix systems Python either uses the OS backlinking mechanism or grows
its own which means that it will cope whether Python is a shared object
or not.

Creating executables, either requires that Python is a shared library
(which has a few issues around names etc) or that the executable 
dynamically loads Python as a shared object. Neither is really that
hard to do although it is probably a bit fiddly.

> In practice, few applications embed Python -- it's much more common to

Few applications embed Python because it is not very easy to do so.
Embedding Python in executables is probably not that hard but we are
talking about embedding Python dynamically.

> have Python extensions, which already are shared libraries.  Also,

There are lots of things which you cannot do if Python is not a shared
library.

    Dynamically embed in other scripting languages.
	Python (and Perl and others) have all benefited an awful lot
	from being able to dynamically load Tk. I am sure that Python
	has a lot to offer other scripting languages but can't simply
	because it is not dynamically loadable.

	See minotaur at http://mini.net/pub/ts2/minotaur.html for
	details on just how this could work.

    Browser plugins.

> serious embedders often want total control over which Python version
> and configuration they use so they wouldn't want to use a standard
> shared library anyway.  So while this motivation is nice in theory, I

I can still have total control over the configuration by simply 
renaming the library that I built to something else.

> doubt that it will save much in practice.  (Hence the low priority I
> give to making a shared library.)

Over the last couple of months I have seen probably one request a week 
for this.

At the very least add an option to build a libpython.a with Position
Independent Code so that it can be linked into shared objects.

-- 
Paul Duffin
DT/6000 Development	Email: pduffin at hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880