> The real problem is making assumptions about what /usr/bin/python is > beyond what the RefMan says. The same sort of problem occurs if a > script writer assumes /bin/sh is bash and uses bash-isms rather than > sticking to the POSIX specification because /bin/sh could be any POSIX > compliant shell (ie ash).
I'm not sure if we're agreeing or disagreeing here. I suspect the problem is that AFAICT nobody who wants /usr/bin/python to be a symlink to alternatives seems to have suggested a precise list of properties that said alternative should have. I had implicitly assumed that the ability to open a random .so module was one such property, which jython will (likely) never satisfy. My basic point is this: If for whatever reason a decision is made to let /usr/bin/python be a symlink, I will not offer jython for such a symlink(*) unless someone documents precisely what properties that symlinked python should have and I can verify that jython satisfies them. Reason being that jython differs from cpython in many more ways than cpython(x) differs from cpython(y). Ben. (*) unless of course there is an overwhelming call for me to do so regardless. -- Ben Burton [EMAIL PROTECTED] | [EMAIL PROTECTED] http://baasil.humbug.org.au/bab/ Public Key: finger [EMAIL PROTECTED] Other people are quite dreadful. The only possible society is oneself. - Oscar Wilde
