Re: Experimental Python packages
> 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
benb@acm.org | bab@debian.org
http://baasil.humbug.org.au/bab/
Public Key: finger bab@debian.org
Other people are quite dreadful. The only possible society is oneself.
- Oscar Wilde
Reply to: