phil.hornby at accutest.co.uk
Mon Feb 2 15:03:08 CET 2004
Thanks for the insight...it was more a general wonderment...as I have
written extensions in C for a while but never tried it...but in other
systems I would NEVER dream of using static linking as it would generally
cause me more hassle than help. The big advantage I see with the ability to
link dynamically is that you can improve functionality/implement fixes in a
plug-in manner instead of having to recompile your entire app. Which is a
very useful feature especially if you have customers who you need to keep
up-to-date over the web as it minimises the downloads required.
I can see that having the freedom to change/augment the implementation is a
powerful arguement against giving this compatibility... Maybe at some point
people will feel that the implementation is mature enough for that level of
code freezing and at that point dynamic linking will become a realistic
Nice to have the insight into why it is as it is though...
"Requirements - what are they I just hack something together that does what
I think they want" ;)
>> I am just wondering if anyone has played with dynamically linking to the
> Historically, nobody has been interested in making the kind of committment
> that binary-level compatiblity between Python shared library images of
> different x.y versions. Such a decision would be viewed as preventing
> necessary change to Python's internals---for instance, either the size
> and layout of all builtin types would be frozen, or access to any fields
> would require calls to shared library functions. It's your choice
> whether to hurt either performance or the freedom of implementation
> details of future Python releases.
> If you're in favor of this kind of compatibility, as opposed to the
> source-level compatibility that Python maintains for 90+% of code
> between releases, then it may be up to you to make a convincing
> case for it.
More information about the Python-list