[Python-Dev] PEP 384 status

[Nick Coghlan]

On Mon, Aug 30, 2010 at 1:43 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sun, 29 Aug 2010 22:16:57 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> (actually, I'm baffled that Windows has such problems, and I would
> suggest that it's not Python's job to shield Windows
> application developers from Windows-specific development issues)

It depends on how you view different versions of a shared library -
with relocatable addresses, there's nothing fundamental preventing you
from allowing separately compiled components to depend on those
different versions, with the dynamic linker placing them at different
points in memory. If you start from an independent binary distribution
mindset and an attitude that the easiest way to ensure backwards
compatibility is to avoid forced upgrades of dependencies, allowing it
makes perfect sense (whereas *nix systems tend work to with a "don't
repeat yourself" philosophy at the system level and are quite happy to
let old binaries and source code become unusable, or at least
incompatible with modern components, as their dependencies update
below them). With the benefit of hindsight, the Windows approach turns
out to have some pretty severe downsides (the name "DLL hell" is well
earned), but there are some positive aspects to the approach.

Back on the main topic, I am not in a position to state that Windows
is the only platform that currently, or will ever, allow two different
versions of the C runtime to be loaded into the same address space (I
thought you could even persuade *nix to do it if you really wanted to,
although you tell me I'm wrong about that). Since part of the point of
PEP 384 is to support multiple versions of the C runtime in a single
process, relying on Windows-specific or post-C89 options  seems
unnecessary when there are platform neutral C89 compatible approaches
that achieve the same end in a way that will be completely obvious to
most C programmers.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia