[Stackless] 'Normal' sys.path being used instead of Stackless one

Richard Tew 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
>> compilation.
> 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 mailing list