2009/1/19 Richard Tew <[email protected]>: > Also, when Python is installed on an operating system the DLLs for > that release version are placed in 'Windows\System32'.
As an aside, I find it a source of some amusement that the Python people see fit to throw the DLL into System32 but steadfastly refuse to add the Python directory or its scripts subdirectory to the PATH environment variable on installation so that Python is actually practical to use. > In order to allow Stackless to be > installable alongside standard Python, we'd have to rename our DLLs. > This cascades.. what else do we need to change to get a Stackless > Windows install to be separate? Yes, it just looks to me like Python itself is a bit antisocial and not amenable to compartmentalised installations. This is of no surprise to me, given the other problems Python has playing nicely with different versions and so on. > Keep in mind that Stackless is intended to be 100% compatible with > standard Python. [...] > Where binary builds made for standard Python don't do this, they > should be directly usable with Stackless. This is pretty much the main issue for me. This is not what I'm seeing in practice, and I don't know where the fault lies. For example, I try to 'import socket' from my embedded Stackless app and it fails to import '_socket'. This could be because it's looking in the wrong place (as my Stackless build didn't build socket, for some reason), but I can see quite clearly that it's looking in my normal Python libs directory, where socket is fully built and operational. And if I do it from my normal Python install, it seems to work. So, something is getting confused along the way, and I guessed - wrongly, it seems? - that it might be a binary incompatibility problem. Or a path problem. >> For me it becomes a maintenance problem where I have to rebuild every >> binary library I may use, whether I am using Stackless functionality >> for a given project or not. With library distribution via easy_install >> and eggs becoming more common, this becomes more problematic. > > Well, I'm not really the target market for 'easy_install'. Whenever > I've used it, I have no idea what it is doing. It's like some magic > shit which is going on and puts something I'm not quite clear on > somewhere I'm not exactly sure of. I like to know when I install > something, what goes where. I guess you're a fan of the traditional ./configure, make, make install then? :) All easy_install really does is put a library in site-packages, the same way as pretty much any installer or a typical setup.py might, for the most part. But if everything is binary compatible as you say, this should Just Work anyway, and may not be relevant in the end. > But that aside, I don't really understand why you are needing to do this. Abridged version: 1) I didn't feel I could overwrite my standard Python installation binaries with the Stackless ones due to apparent compatibility issues; 2) I see what appears to be compatibility issues, couldn't find documentation confirming or denying this one way or the other, so assumed they existed and looked for a workaround; 3) I'd appreciate any solution that allows me to (a) use Stackless as part of an embedded app and (b) doesn't require that I recompile binary 3rd party libraries downloaded from easy_install etc. Thanks, Ben Sizer _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
