On Mon, Aug 30, 2010 at 1:43 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 29 Aug 2010 22:16:57 +1000 Nick Coghlan <ncoghlan@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@gmail.com | Brisbane, Australia