[Stackless] 'Normal' sys.path being used instead of Stackless one
richard.m.tew at gmail.com
Mon Jan 19 18:12:43 CET 2009
On Mon, Jan 19, 2009 at 11:53 AM, Ben Sizer <kylotan at gmail.com> wrote:
> 2009/1/19 Richard Tew <richard.m.tew at gmail.com>:
>> On Mon, Jan 19, 2009 at 10:07 AM, Ben Sizer <kylotan at gmail.com> wrote:
>>> place (as my Stackless build didn't build socket, for some reason),
>> I expect this is a problem with your compilation environment.
>> If a standard part of Python fails to compile, you need to find out
>> why and make sure it compiles before using the results of this
> But I don't see the relevance there - if Stackless is using my
> pre-installed Python path (it is), and that path contains a pre-built
> socket library binary (it does), and Stackless is binary compatible in
> all reasonable cases with normal Python (you assure me it is, and I
> have no reason to doubt that), then something's surely wrong with the
> runtime environment rather than the build environment. Sometimes you
Sure. But if socket isn't compiling, I personally consider it worth
getting it to compile and working out why it didn't as I consider its
failure to compile unexpected and unacceptable.
> can't build something because you lack the extra libraries for it, but
> pre-built binaries for your platform and C runtime should work fine.
Socket is not one of these things. It should compile reliably and
consistently. In general, I consider its failure to compile to be a
sign of larger problems with the compilation environment.
I can accept ignoring the compilation of optional projects that have
real external dependencies like SSL or bzip, but not socket.
More information about the Stackless